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ABSTRACT 


Currently,  the  Navy  stores  and  retains  data  in  multiple  data  warehouses,  in  various 
formats,  in  numerous  legacy  systems.  The  Navy’s  Bureau  of  Personnel  is  responsible  for 
four  distinct  data  stores  that  house  unique  data  for:  Active  Duty  Officers,  Active  Duty 
Enlisted,  Drilling  Reserve  Officers  and  Enlisted,  and  all  Inactive  Service  members. 
Decision-makers  within  the  Navy  have  proposed  combining  the  data  into  one  cleansed, 
metadata  tagged,  indexable  and  searchable  enterprise  data  environment.  This 
environment  will  resolve  redundant  storage  issues,  as  well  as  eliminate  outdated,  end-of- 
lifecycle  equipment  and  legacy  infrastructure.  This  research  will  focus  on  the  following. 
First,  this  research  will  focus  on  the  current  state  of  IT  systems  from  the  Department  of 
Defense  (DoD)  level  through  the  Department  of  the  Navy  (DoN)  level  to  the  focal 
system — the  Reserve  Headquarters  Support  (RHS)  system.  Second,  research  of  current 
departmental  guidance  as  to  the  desired  state  of  these  systems  will  be  conducted  and 
summarized.  Third,  economic,  technical,  and  strategic  management  theories  will  be 
studied  and  applied  in  order  to  conduct  an  economic  analysis  of  the  possibility  of 
migrating  the  RHS  application  to  a  more  modern  IT  solution.  In  the  final  chapter, 
conclusions  and  recommendations  are  provided  concerning  the  most  attractive  way  to 
proceed  with  the  RHS  application.  Finally,  possibilities  for  follow-on  work  are  discussed. 
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I.  INTRODUCTION 


A.  PURPOSE 

Research  for  this  thesis  will  focus  on  conducting  technical,  economic  and 
personnel  implication  studies  to  detennine  whether  the  Navy  should  focus  on  upgrading 
the  current  data  management  function  for  the  Reserve  Headquarters  Support  (RHS) 
Information  Technology  (IT)  application.  It  will  examine  the  current  and  desired  state  of 
information  systems — from  the  Department  of  Defense  (DoD)  organization  level  down  to 
the  RHS  system  level.  The  research  will  then  explore  methodologies — including 
technical  and  managerial  methods — best  suited  to  a  possible  migration  of  RHS  to  more 
modem  business  architecture.  Finally,  if  applicable,  the  researcher  will  present 
alternative  solutions  to  meet  this  objective  and  will  conduct  an  economic  analysis  to 
identify  the  most  qualified  solution. 

B.  BACKGROUND 

Currently,  the  Navy  stores  and  retains  personnel  data  in  multiple  databases 
supporting  multiple,  separate  functions  in  geographically  dispersed  locations. 
Potentially,  the  facilities  and  the  data  they  store  could  be  combined  in  fewer  facilities. 
Additionally,  this  study  will  research  whether  the  current  system  architecture  leads  to 
logistical  issues  associated  with  such  storage  and  if  problems  exist  due  to  the  age  of  the 
systems  that  currently  perform  these  functions.  Other  areas  of  research  include  potential 
sources  of  inefficiencies  and  unnecessary  system  redundancies.  Further  examination  of 
these  data-storage  facilities  will  be  conducted  to  determine  if  business  best  practices  such 
as  sharing  or  combining  similar  functions  between  organizational  entities  or  throughout 
the  enterprise  are  leveraged. 

Recently  problems  have  surfaced  as  the  Navy  shifts  towards  integration  of  both 
active  and  reserve  components  (AC/RC).  These  problems  have  created  personnel 
management  difficulties  not  only  from  an  external  DoD  organization  level,  but  also  from 
an  internal  Department  of  the  Navy  (DoN)  level.  This  paper  will  research  whether  these 
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problems  are  caused  by,  or  could  be  diminished  by  the  application  of  IT  solutions  and 
what  these  solutions  might  entail.  In  addition  to  the  potential  issues  previously  mentioned 
(disparate  systems,  lack  of  sharing/combining),  the  component  information  technology 
infrastructures  rely  upon  antiquated  database  technologies  that  were  put  into  production 
in  the  1970s  and  1980s.  Issues  associated  with  systems  that  are  this  old  will  also  be 
examined. 

Policy  and  operational  considerations  for  both  AC  and  RC  organizations  must  be 
researched  to  identify  common  ground,  as  well  as  disparate  factors  concerning  both  of 
these  organizations’  policies  and  operations.  The  implications  of  the  research  within 
these  constraints  is  that  combining  the  organizations’  data  solutions  may  or  may  not  be 
feasible  for  reasons  other  than  those  strictly  technical  or  economic. 

The  framework  under  which  this  research  will  be  completed  will  identify  current 
operations,  procedures,  business  rules  and  economics  of  the  existing  systems  at  all  levels 
of  the  DoD.  Once  the  research  of  the  current  information  systems  and  desired  states  has 
been  discussed,  comparable  organizations — either  internal  or  external  to  the  government 
and  that  have  completed  projects  of  a  similar  size  and  scope — will  be  identified  for 
benchmarking  purposes.  In  addition,  the  researcher  will  review  the  most  current  research 
in  the  field  of  enterprise  architecture  to  identify  common  themes  that  exist  in 
organizations  that  have  successfully  transitioned  their  IT  systems.  These  lessons  learned 
will  be  applied  to  this  research,  acting  as  a  roadmap  for  similar  DoD  and  subsidiary  IT 
systems  and  their  own  efforts  for  transition.  Ultimately,  after  the  research  materials  are 
examined,  the  researcher  will  make  recommendations  about  the  future  direction  of  the 
RHS  system. 

C.  SCOPE 

One  of  the  goals  in  conducting  this  study  is  to  determine  if  the  migration  of  the 
Reserve  Headquarters  Support  application  and  its  associated  data  is  warranted.  One 
potential  alternative  solution  is  the  Defense  Integrated  Military  Human  Resource  System 
(DIMHRS),  which  is  supported  by  the  DoD  through  the  Business  Transformation  Agency 
(BTA).  Another  potential  alternative  is  for  migration  to  the  Enterprise  Data  Environment 
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(EDE) — which  is  currently  under  development  at  Space  and  Naval  Warfare  Systems 
Command  (SPAWAR)  Systems  Command,  New  Orleans  (SSC  NOLA).  To  reach 
conclusions  and  formulate  recommendations,  the  researcher  will  conduct  an  economic 
analysis  comparing  the  three  alternatives  (current  system,  DIMHRS,  and  EDE)  from  both 
a  cost  and  benefit  perspective,  including  quantitative  and  qualitative  measures. 

A  portion  of  this  paper  will  be  technical  in  nature.  However,  specific  technical 
solutions  to  the  owners  of  RHS  will  not  be  rendered.  Instead,  if  and  when  warranted, 
general  guidelines  for  the  successful  future  positioning  of  the  RHS  will  be  offered.  From 
an  economic  standpoint,  this  study  will  present  research  to  determine  the  current  costs  of 
doing  business  and  what  the  proposed  solutions  costs  would  be.  These  costs  will  include 
investment  as  well  as  sustainment  costs.  Additionally,  the  expected  benefits  provided  by 
each  of  the  alternatives  will  be  examined.  The  cost  estimates  of  proposed  solutions 
within  this  paper  are  not  meant  to  be  exact,  but  they  are  provided  in  order  to  make  a 
comparison  possible  by  using  best  estimates  based  on  current  information.  In  addition, 
the  research  conducted  will  break  down  the  technical  and  economic  aspects  of  the  focus 
system  (RHS)  to  a  level  that  would  ensure  reasonable  projections  for  future  development 
efforts  and  costs. 

Additional  value  of  this  study  exists  in  the  possibility  that  other  military 
organizations  looking  to  do  similar  work  might  leverage  the  work  completed  in  this 
thesis.  This  research  will  not  aim  to  provide  actual  technical  solutions;  it  will,  however, 
render  a  high-level  assessment  of  the  technical  feasibility  necessary  to  meet  the  stated 
requirements.  Further,  this  assessment  could  provide  a  starting  point  for  further  research 
into  technology-specific  solutions  for  migrating  RHS  from  its  current  state  to  a  desired 
state.  Economically,  an  analysis  of  current  costs  to  operate  and  maintain  the  RHS 
application  can  provide  a  reasonable  representation  of  the  current  state  (as  this  is  a  known 
quantity  and  a  matter  of  accounting).  However,  the  forecasting  of  costs  will  be  limited  to 
those  factors  that  can  be  estimated  without  a  specific  technology  solution  in  mind. 
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D.  METHODOLOGY 


The  research  methods  used  in  this  paper  consisted  of  interviewing  system  owners 
and  stakeholders,  reading  topic  related  literature  (both  academic  and  professional),  and 
applying  concepts  that  the  author  has  learned  through  fonnal  education  and  industry 
related  experience.  A  preponderance  of  the  data  enabling  the  research  for  Chapters  II  and 
III  of  this  thesis  was  collected  from  SSC  NOLA,  Commander  Navy  Reserve  Forces 
Command  (CNRFC),  the  Navy  Program  Executive  Office  for  Enterprise  Infonnation 
Systems  (PEO  EIS),  and  the  Navy  Manpower  Personnel  Training  and  Education  (MPTE) 
organizations.  Chapter  IV  references  material  that  was  more  scholarly  and  guidance- 
oriented — including  works  by  industry  experts  and  academics  working  in  the  area  of 
software  and  enterprise  architectures.  Other  useful  resources  for  this  research  included: 
lectures  attended  at  the  Naval  Postgraduate  School,  various  Internet  sites,  and  discussions 
held  with  professors  and  the  researcher’s  Thesis  Team.  Finally,  additional  data  was 
gathered  from  multiple  other  resources  relevant  to  the  focal  organizations  and  subject  at  a 
level  appropriate  to  the  scope  of  this  thesis. 

The  researcher  used  multiple  research  methods  to  collect  data  for  this  study — 
including  interviews  with  the  CNRFC  and  SSC  NOLA  staff.  Additionally,  interviews 
and  one-on-one  discussions  with  professors  were  used  to  gain  direction  as  to  where  data 
pertinent  to  this  topic  could  be  attained.  Once  these  sources  of  data  were  discovered,  the 
researcher  accumulated  and  researched  all  the  available  secondary  data  regarding  the 
support  of  RHS.  Thus,  the  research  conducted  in  the  completion  of  this  thesis  was 
secondary  in  nature.  All  sources  cited  in  the  study  were  researched  for  validity  and 
accuracy  before  being  cited. 

This  remainder  of  this  paper  is  organized  as  follows.  First,  in  Chapter  II,  the 
current  state  of  IT  systems  at  all  levels  of  the  DoD  is  examined  down  to  the  RHS  level. 
Second,  based  upon  a  study  of  the  existing  literature,  Chapter  III  examines  the  desired 
state  of  these  same  systems.  In  Chapter  IV,  methods  for  bridging  the  gap  between  the 
current  state  and  the  desired  end-state  are  examined  including  a  relevant  economic 
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analysis.  Finally,  based  upon  the  preceding  chapters,  conclusions,  recommendations  and 
answers  to  the  primary  and  secondary  questions  posed  by  this  research  are  given.  These 
research  questions  are  as  follows. 

Primary  research  question: 

What  are  the  implications  of  migrating  from  the  Navy ’s  current  disparate  data 
warehousing  architecture  to  an  integrated  solution  with  a  focus  on  the  Reserve 
Headquarters  Support  ( RHS )? 

Subsidiary  research  questions: 

What  is  the  cost  of  the  current  data  warehouse  solution;  how  much  would  it  cost 
to  upgrade,  and  what  cost  model  can  be  used  to  appropriately  forecast  the  cost  the 
upgrade? 

What  is  the  current  technical  architecture  that  supports  data  warehousing  of  the 
Navy ’s  data,  and  is  it  appropriate? 

How  would  migration  of  the  RHS  be  carried  out  from  a  technical  standpoint? 
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II.  CURRENT  STATE  OF  INFORMATION  SYSTEMS 


A.  DEPARTMENT  OF  DEFENSE  (DOD) 

The  Department  of  Defense  (DoD)  is  a  massive  organization  that  has  operated  in 
a  highly  dynamic  environment  for  many  years;  one  bi-product  of  that  situation  is  that  the 
DoD’s  financial  and  manpower  infonnation  stores  are  highly  partitioned  or  siloed  along 
Military  Active  Component  (AC)  and  Reserve  Component  (RC)  lines,  as  well  as  between 
military  and  civilian  government  organizations.  This  structure  has  forced  the  separate 
organizations  to  create  infrastructure  to  support  themselves  separately.  This  separation 
has  made  it  difficult  to  share  information  among  the  components  of  the  DoD — a  problem 
glaringly  evident  in  issues  with  personnel  assignment  during  Operation  Iraqi  Freedom 
(OIF)  and  Operation  Enduring  Freedom  (OEF).  Additionally,  separate  staffs  and 
facilities  have  been  created  and  continue  to  operate  in  their  component-specific 
environments. 

The  creation  of  the  Business  Transformation  Agency  (BTA)  in  2006  was  the 
DoD’s  response  to  remedy  this  situation.  The  BTA  has  mandated  that  all  organizations 
within  the  DoD  work  toward  the  creation  and  sustainment  of  an  enterprise  architecture. 
Of  particular  interest  to  this  study  is  the  development  and  deployment  of  the  Defense 
Integrated  Military  Human  Resource  System  (DIMHRS),  which  is  to  replace  all  of  the 
personnel  systems  currently  in  use  within  the  DoD  (military  and  civilian).  Of  course,  this 
will  be  phased  into  production  over  a  period  of  several  years — with  the  Anny  scheduled 
to  be  the  first  organization  to  go  live  with  the  DIMHRS.  Per  the  Anny  DIMHRS  Web 
site,  the  implementation  date  of  March  1,  2009,  was  postponed.  In  fact,  the  whole 
program  has  been  suspended  until  further  notice  (US  Army  PEO  EIS,  2009). 

However,  the  fact  remains  that  the  DoD  is  moving  towards  integration  of  its  IT 
systems;  what  form  that  transformation  takes  remains  to  be  seen.  What  is  important  to 
this  study  is  the  fact  that  support  exists  at  the  highest  levels  of  our  government  to  ensure 
the  technology  it  possesses  within  its  organizations  is  capable  of  meeting  the  missions  of 
the  future. 
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B.  DEPARTMENT  OF  THE  NAVY  (DON) 


The  Navy  currently  stores  and  retains  its  data  in  multiple  data  warehouses,  in 
various  data  element  fonnats,  in  many  disparate  legacy  systems.  The  Navy’s  Bureau  of 
Personnel  is  responsible  for  five  distinct  applications  that  track,  store  and  manipulate  data 
for  Active  Duty  Officers,  Active  Duty  Enlisted,  Drilling  Reserve  Officers  and  Enlisted, 
and  all  Inactive  Service  members.  These  applications  are  authoritative  data  sources 
(ADS),  which  are  “a  designated,  or  agreed  upon,  trusted  source  of  information”  (US 
Army  CIO,  2009).  These  applications  support  and  interface  with  several  organizations’ 
systems — both  internal  (such  as  recruiting  systems)  and  external  to  the  Navy  (such  as  the 
Defense  Finance  and  Accounting  System  (DFAS),  which,  among  other  services,  is  the 
military  pay  system).  “Per  the  DIMHRS  Milestone  B  Operational  Requirements 
Document,  there  are  five  Navy  personnel  systems  that  are  subsumed  by  DIMHRS”  (ASN 
(M&RA),  2009,  p.  7). 

•  Navy  Enlisted  System  (NES) 

•  Officer  Personnel  Infonnation  System  (OPINS) 

•  Navy  Standard  Integrated  Personnel  System  (NSIPS) 

•  Reserve  Headquarters  Support  (RHS) 

•  Inactive  Manpower  and  Personnel  Management  Infonnation  System 

(IMAPMIS) 

The  DIMHRS  only  covers  personnel-  and  pay-related  functionality.  Therefore, 
although  the  bulk  of  these  systems’  functionality  will  be  covered  by  the  DIMHRS,  they 
do  have  some  non-personnel-related  functions  that  will  be  maintained  separately.  In  the 
next  section,  we  examine  the  specific  interfaces  these  five  applications  have  within  the 
Navy  Manpower,  Personnel,  Training  and  Education  (MPTE)  environment. 

1.  Manpower,  Personnel  Training  &  Education  (MPTE)  IT 

According  to  the  Navy  Total  Force  (NTF)  team,  “The  MPTE  domain  was 
officially  created  in  July  2005  by  the  merger  of  the  Manpower  and  Personnel  with 
Training  and  Education  commands”  (NTF,  2009,  p.l).  This  move  was  made  in  an  effort 
to  ensure  that  operations  undertaken  by  the  Navy  are  supported  in  the  most  efficient 
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manner  possible  utilizing  the  Total  Force  (all  personnel  in  either  active  or  reserve  status). 
Due  to  this  organizational  restructuring,  all  of  the  IT  assets  of  the  merging  entities  have 
been  placed  under  the  purview  of  the  Deputy  Chief  of  Naval  Operations  (Manpower, 
Personnel,  Training  &  Education).  With  this  combination,  the  IT  system  has  become 
more  complex  due  to  the  greater  size  and  increased  functionality  housed  within  one 
system.  However,  this  combination  places  all  of  the  authoritative  data  sources  of  the 
Navy  under  the  direct  control  of  one  organization,  which  should  aid  in  achieving  the 
goals  of  the  DoN  and  DoD  of  enterprise  alignment  of  IT  systems. 

a.  Issues  in  the  Environment 

The  focus  system  of  this  study,  RHS,  lies  within  the  MPTE  IT  domain, 
which  is  predominately  concerned  with  the  management  of  all  Navy  personnel  and  all 
functions  associated  with  human  resource  management.  As  discussed  previously,  five 
separate  systems  make  up  the  personnel  authoritative  sources  portion  of  the  MPTE  IT 
System:  NES,  OPINS,  NSIPS,  RHS,  and  IMAPMIS.  Actually,  NSIPS  is  a  record-entry 
application  used  to  interface  with  the  other  four  systems;  thus,  the  remaining  four  systems 
comprise  the  entire  authoritative  data  sources  concerning  personnel,  as  depicted  in  Figure 
1. 
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Figure  1.  Navy  Authoritative  Data  Sources  for  Personnel  (From  Aries  Systems 

International,  Inc.,  2005) 


In  this  section,  we  will  focus  on  some  of  the  issues  associated  with  the 
MPTE  system  environment,  in  particular: 

•  Age  of  the  technology  (both  hardware  and  software), 

•  Number  of  associated  interfaces  with  these  systems, 

•  System  maintenance,  and 

•  System  complexity. 

(1)  Age  of  the  Technology.  A  document  retrieved  from  the 
DoN  Website  entitled  “Draft  DON  DIMHRS  Concurrent  Review”  concerning  the  age  of 
the  MPTE  system  components  states,  “All  of  these  systems,  except  NSIPS,  have  been  in 
sustainment  mode  since  mid- 1970.  Only  congressionally  mandated  improvements  and 
functional  maintenance  have  been  done  on  the  systems”  (ASN  (M&RA),  2009,  p.  7). 
This  fact  presents  myriad  associated  problems,  including  dated  hardware,  dated  software, 
overburdened  and  inefficient  architecture,  lack  of  qualified  technicians,  and  necessarily 
inefficient  procedures. 
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If  Moore’s  Law  is  applied — which  states  that  the  number  of 
transistors  that  can  be  placed  on  a  chip  doubles  roughly  every  two  years — and  assuming 
an  average  in-service  system  date  of  1979,  then  the  four  authoritative  data  source  systems 
are  about  fifteen  generations  behind  the  latest  technology.  Further,  according  to  Kanellos 
(2005),  this  trend  “will  continue  for  at  least  a  decade”  (p.  1).  Thus,  if  not  changed  prior  to 
2015,  these  systems  will  be  eighteen  full  generations  behind  the  latest  technology.  Given 
the  pace  with  which  the  DIMHRS  has  progressed,  this  possibility  seems  to  be  highly 
likely.  This  scenario — combined  with  the  issues  associated  with  the  DoD  acquisition 
process  of  large-scale  IT  systems — does  not  bode  well  for  the  replacement  of  these 
systems  anytime  in  the  very  near  future. 

(2)  Number  of  Interfaces.  According  to  the  DoN  Program 
Executive  Office  (PEO)  Enterprise  Information  Systems  (EIS),  there  are  hundreds  of 
interfaces  among  the  systems  focused  on  in  this  paper,  with  many  of  them  sharing 
multiple  files.  These  files  are  shown  in  the  following  figure  (Murphy,  2007).  As  one  can 
see  from  the  graph,  the  REIS  alone  has  over  75  interface  files,  which  we  will  inspect  in 
the  following  section. 


Nurberof  Irterfaces/lrteifaceFies  Per  System 


Figure  2.  Number  of  Interfaces/Interface  Files  per  System 

(From  Murphy,  2007,  Slide  47) 
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Over  the  years,  the  number  of  interfaces  has  continued  to  grow  as 
new  systems  are  added  within  the  enterprise,  which  in  turn  require  connections  to  the 
MPTE  domain.  This  trend  will  likely  continue.  As  the  number  of  system  interfaces 
increases,  the  performance  of  a  system  is  degraded.  This  is  due  to  several  factors, 
including: 

•  The  overall  system  complexity  increases  as  more  systems  are  added. 

•  Each  interface  requires  system  hand-offs  at  the  software  level, 
necessitating  communication  between  systems  via  protocols,  thus  taking 
processor  time. 

•  Hardware  components  are  constrained,  as  they  are  utilized  more  heavily 
and  frequently. 

In  addition  to  these  issues,  advances  in  hardware  have  outpaced 
those  made  in  software.  This  can  be  attributed  to  many  factors — including  the  fact  that 
software  is  more  complex,  as  it  is  based  upon  logical  properties  rather  than  physical 
factors  that  dictate  hardware  development  (Osmundson,  2009). 

(3)  System  Maintenance  (Ad-hoc  Fixes  to  Interface  Issues).  The 
issues  just  discussed  of  old  technology  and  multiple  interfaces  greatly  increase  the 
complexities  of  system  maintenance.  Aside  from  the  purely  technical  issues,  the 
personnel  problems  associated  with  these  older  systems  are  complex.  Most  IT 
professionals  trained  today  are  not  being  trained  in  the  technologies  used  in  the  1970s. 
Additionally,  the  aging  information  systems  are  mirrored  by  an  aging  workforce  who  are 
not  trained  in  the  latest  technologies  and  have  a  high  attrition  rate.  Finally,  many  people 
have  moved  on  to  different  careers,  to  different  parts  of  the  organization,  or  have  simply 
retired — creating  a  serious  threat  of  not  having  enough  qualified  people  to  work  on  these 
systems. 

(4)  Data  Issues  (Quality,  Synchronization,  Maintenance).  Within 
the  MPTE  IT  domain,  there  are  several  issues  related  to  the  data  that  it  uses,  owns,  and 
creates.  Of  these  issues,  those  associated  with  quality,  synchronization,  and  maintenance 
are  focused  on  here.  Each  of  these  issues  is  distinct  in  the  problems  it  presents;  however, 
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each  issue  is  intertwined  and  cannot  be  separated  and  fixed  in  isolation.  If  data  quality 
and  synchronization  issues  are  addressed,  it  logically  follows  that  maintenance  problems 
will  be  diminished. 

Data  Requirements 

DoD  l  Legislative/  Operational  f  Analytical 


RHS  CeTARS 

CNRF  NETC 


Figure  3.  Current  MPTE  Data  Management  Environment 

(From  Pavelec,  2008,  p.  3) 
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Figure  3  illustrates  some  of  the  issues  associated  with  the  current 
data  architecture  of  the  MPTE  domain.  Per  the  Data  Management  and  Integration  (DMI) 
Roadmap'. 

[T]he  MPTE  enterprise  currently  relies  on  “siloed”  systems  within  fragmented 
organizations.  Because  of  the  isolation  of  data  within  outdated  architecture,  there 
are  inconsistent  data  standardization  and  formatting,  inconsistencies  with  data 
quality,  multiple  costly  interfaces,  and  nonexistent  overarching  enterprise  data 
governance.  (Pavelec,  2008,  p.  3) 

If  we  examine  the  issue  another  way,  we  see  the  following  data- 
related  issues  within  the  current  environment: 

•  Poor  data  quality — inconsistencies  exist  in  the  current  environment  related 
to  data  availability,  relevance,  action-ability,  consistency,  validity,  and 
trustworthiness. 

•  Poor  data  interoperability — this  exists  between  the  multiple  system 
interfaces;  data  re-use  is  difficult  due  to  a  lack  of  common  standards. 
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•  Difficult  maintenance  of  data — this  is  related  to  the  previously  described 
issues  with  quality  and  maintenance  and  is  exacerbated  by  the  lack  of 
enterprise  data  governance. 

(5)  System  Complexity.  Figure  4  portrays  the  complexity  of  the 
MPTE  IT  environment.  In  this  diagram,  a  picture  is  painted  of  many  of  the  problems 
highlighted  in  this  paper:  siloed  databases/functionality,  too  many  interfaces,  and 
complexity,  to  name  a  few.  What  this  picture  does  not  capture  is  the  actual  complexity  of 
the  system,  as  it  is  a  great  simplification  of  the  MPTE  IT  environment.  The  actual  real 
complexities  and  problems  stem  from  such  things  as  system  reach-backs  (which  allow 
necessary  system  interfaces  to  be  maintained  that  are  not  included  in  new  development 
efforts),  poor  system  documentation,  and  an  overall  lack  of  understanding  of  and  about 
the  system.  It  is  probable  that  no  one  person  fully  understands  the  entire  system  or  what 
it  does.  Each  person  associated  with  it  may  understand  his  or  her  own  small  piece,  but 
may  have  little  appreciation  for  how  the  entire  system  works. 
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Figure  4.  MPTE  System  Overview  (From  Aries  Systems  International,  Inc.,  2005) 

No  one  could  understand  such  a  complex  system.  This  lack  of 
understanding  leads  to  problems — downstream  issues  are  created  when  an  upstream 
system  changes.  Often,  the  upstream  system  can  adversely  affect  the  downstream  system 
without  knowing  it;  the  upstream  personnel  might  not  even  know  that  the  downstream 
system  exists.  This  type  of  problem  can  even  create  an  environment  in  which  easy 
changes  can  become  highly  complex  and  may  even  be  avoided  so  as  to  not  cause 
problems  for  other  systems.  Decision-makers  may  implement  critical  changes  without 
notifying  interfaced  systems,  thus  creating  a  ripple  effect  of  errors.  If  policy-makers  do 
not  address  these  issues,  the  associated  system  problems  will  continue  to  grow  and  will 
eventually  create  serious  trouble. 
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2.  Map  of  Current  Environment 


The  next  section  examines  the  components  of  Figure  4.  In  this  diagram  displays 
several  shapes,  lines,  arrows,  colors,  and  actors,  as  well  as  a  large,  light  blue  oval  that 
surrounds  a  tan  oval.  Anything  inside  the  tan  oval  describes  or  depicts  the  components 
that  make  up  the  MPTE  environment  (many  of  which  have  been  discussed  in  this 
project).  The  light  blue  oval  surrounding  the  tan  represents  systems  that  are  direct 
external  interfaces  to  the  MPTE  system.  Outside  of  that  are  systems  with  which  the 
MPTE  system  interfaces  through  its  direct  external  links. 

The  basic  scheme  of  this  picture  inside  the  large,  tan  oval  is  that  the  different- 
colored  ovals  depict  the  functional  domains  within  the  overall  system.  Functional 
domains  are  closely  related  to  business  functions;  each  domain  performs  a  function 
related  to  its  pertinent  business  or  operational  function.  In  fact,  there  may  be  more  than 
one  oval  of  the  same  color  that  is  intertwined.  In  either  case,  the  name  of  the  functional 
domain  is  contained  within  one  of  the  imbedded  blue  ovals.  Each  of  the  multi-colored 
domain  ovals  (or  clusters  of  ovals)  contains  one  and  only  one  blue  oval.  Therefore,  we 
can  breakdown  the  MPTE  system  into  its  functional  areas  as  follows: 

•  Archives — This  system  stores  official  Navy  personnel  files  electronically. 

•  Personnel  (Field  Entry) — These  systems  are  used  by  authorized  users  to 
edit,  update,  and  delete  information  pertaining  to  Navy  personnel. 

•  Personnel  (Data  Repository) — This  system  stores  personnel 
information/data  so  it  can  be  maintained,  retrieved  from,  and  written  to. 

•  Distribution  (Detailing  and  Assignment) — This  domain  enables  authorized 
users  to  manage  human  resource  assets  in  regards  to  duty  assignments. 

•  Recruiting — This  system  tracks  applicants  who  are  in  the  process  of 
joining  the  Navy.  Once  affiliated,  these  records  form  the  base  of  Navy 
personnel  records. 

•  Education — This  system  tracks  scheduled,  formal  education  and  other 
educational  pursuits  completed  by  Navy  personnel. 

•  Training  (Authoritative  Sources) — This  system  tracks  scheduled  and 
completed  training  by  Navy  personnel  at  the  individual  and  unit  level. 

•  Fiscal — This  system  tracks  all  budget-related  items  for  the  Navy. 
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•  Manpower  (Authoritative  Source) — This  system  is  supported  by  the  Total 
Force  Manpower  Management  System  (TFMMS)  that  “provides 
capabilities  for  storage  and  retrieval  of  historical,  current,  budget,  and  out- 
year  manpower  data.  It  also  provides  access  to  current  manpower  data  for 
resource  sponsors,  claimant,  etc.”  (CNP,  2009,  p.  1) 

•  Navy  Personnel  Research,  Studies,  and  Technology  (NPRST) — this 
system  conducts  research  and  studies  and  applies  technology  to  solve 
Human  Resource  (HR)-related  problems.  (NPRST,  2009) 

•  Personnel  (Authoritative  Sources) — This  system  provides  manpower, 
personnel  and  pay  management  support. 

This  breakdown  is  further  illustrated  in  Figure  5. 
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Figure  5.  Navy  Functional  Business  Domains  (From  SSC  NOLA,  2008,  Slide  4) 


Within  each  of  the  functional  areas  (depicted  in  Figure  5)  are  silver  rectangles 
containing  acronyms.  These  are  the  applications  that  support  the  parent  function.  Many 
of  these  applications  are  represented  in  Figure  5  as  they  relate  to  their  functional 
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domains.  Additionally,  arrows  extend  from  and  point  to  the  different  functional  domains, 
representing  the  interface  relationships.  These  arrows  may  have  boxes  on  them  that 
describe  the  basic  types  of  information  that  is  flowing  over  these  interfaces.  Finally, 
actors,  in  the  shape  of  people  at  their  desks  in  Figure  4,  represent  the  users  of  the  system. 
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Figure  6.  Navy  Authoritative  Data  Sources  for  Training 
(From  Aries  Systems  International,  Inc.,  2005) 

The  preceding  figure  is  used  to  illustrate  a  small  portion  of  the  system 
flow.  The  two  functional  domains  depicted  are  the  Personnel-Authoritative  Sources  and 
Training- Authoritative  Sources.  One  key  point  is  illustrated  by  the  two  blue  arrows 
pointing  from  the  Personnel  domain  to  the  Training  domain  and  the  boxes  superimposed 
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over  them.  Here,  there  are  two  different  colored  arrows.  These  arrow  colors  match  the 
application  rectangles  borders  from  which  they  are  coming.  In  this  example,  information 
from  both  the  IMAPMIS  application  and  the  RHS  application  (both  in  the  Personnel 
domain)  is  being  transferred  to  the  CeTARS  application  within  the  Training  domain. 

The  basic  symbols  in  the  illustration  above  depict  what  types  of  information  flow 
through  the  MPTE  system  and  the  complexity  of  the  environment. 

Now,  armed  with  a  general  understanding  of  the  MPTE  IT  environment,  we  will 
focus  our  attention  to  one  of  the  applications  within  the  Personnel-Authoritative  Sources 
functional  domain,  the  Reserve  Headquarters  Support  (RHS). 

C.  RESERVE  HEADQUARTERS  SUPPORT  (RHS) 

Per  the  Department  of  the  Navy  (DoN)  Program  Executive  Office  (PEO)- 
Enterprise  Information  Systems  (EIS),  the  “Reserve  Headquarters  Support  (RHS)  is  a 
CNRFC  mission-critical  system  used  in  the  data  collection  and  dissemination  process 
necessary  for  command  and  control  of  SELRES  Mobilization”  (as  cited  in  Murphy,  2007, 
Slide  30). 

Although  the  above  definition  gives  an  idea  about  what  RHS  does,  it  does  not 
explain  the  system’s  mission  completely.  This  section  will  take  an  in-depth  look  at  the 
RHS  application  by  describing  its  functionality,  environment,  interfaces,  and  architecture. 
After  the  system  has  been  described,  this  project  will  examine  the  issues  the  system  faces 
in  regards  to  the  aforementioned  features. 

1.  Functionality 

At  a  high  level,  the  RHS  “provides  automated  storage,  maintenance/update, 
reporting  (e.g.,  accounting,  management,  and  strength),  distribution  of  manpower  and 
personnel  information,  recall/mobilization  status,  and  drill  pay  on  all  drilling  reserve 
Navy  personnel”  (JR&IO,  2004,  p.  10).  As  described  earlier  in  the  discussion  of  the 
MPTE  environment,  the  RHS  lies  within  the  functional  domain  of  Personnel- 
Authoritative  source.  This  means  that  the  RHS,  from  the  Navy  perspective,  is  the  one- 
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stop  shop  for  all  Reserve  personnel-related  infonnation.  Therefore,  any  other  system — 
internal  or  external  to  the  MPTE  IT  environment — that  requires  information  on  Navy 
Reserve  personnel  needs  to  interface  with  the  RHS  to  obtain  such  information.  This 
access  is  critical  to  the  military,  especially  as  the  trend  towards  joint  military  operations 
continues.  In  the  future,  the  RHS  needs  to  be  open  to  not  only  Navy  systems,  but  to  all 
Department  of  Defense  systems  that  need  information  concerning  Navy  Reserve 
personnel.  The  challenge  here  lies  in  the  fact  that  the  current  RHS  architecture  is  not  set 
up  to  serve  this  purpose  but  will  need  to  change  to  serve  this  function. 

2.  Whom  It  Supports 

As  previously  stated,  the  RHS  is  the  authoritative  data  source  for  the  Navy 
Reserve  Force;  as  such,  it  is  “the  central  data  processing  point  between  265  Navy 
Reserve  field  activities  and  all  Navy  and  DoD  pay/personnel  systems”  (Murphy,  2007, 
slide  30).  Further,  the  application  “supports  57,000  Selected  Reservists”  (2007,  slide  30). 
The  implications  of  these  facts  is  that  to  leverage  the  personnel  assets  of  the  Navy 
Reserve,  outside  systems  must  interface  with  the  RHS,  and  the  RHS  must  be  set  up  to 
reciprocate.  Although  today,  the  active  duty  Navy  personnel,  as  well  as  the  other 
Services,  are  utilizing  Navy  Reserve  personnel  assets  as  tracked  by  the  RHS.  This  is  not 
due  to  the  functionality  of  the  RHS.  Many  times  these  assets  are  utilized  in  spite  of  or 
without  the  use  of  the  RHS.  What  has  been  discovered  is  that  even  within  the  Navy,  it  is 
not  possible  for  applications  to  leverage  the  information  of  other  applications  within  the 
MPTE  environment  due  to  incompatible  architectures  and  data  structures,  as  well  as  other 
problems.  In  the  future,  the  RHS  needs  the  functionality  to  not  only  seamlessly  interface 
with  internal  MPTE  applications,  but  to  also  interact  with  other  organizations  external  to 
MPTE.  This  will  allow,  for  instance,  an  undermanned  U.S.  Army  unit  that  is  conducting 
a  critical  operation  to  access  the  description  of  a  Navy  Reserve  person  that  may  be  a 
match  for  its  needs.  However,  the  RHS  as  it  exists  today  does  not  contain  this  type  of 
functionality.  In  the  next  section,  we  will  explore  the  current  RHS  architecture,  its 
environment  and  the  interfaces  that  the  system  maintains. 
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3.  Map  of  the  Technical  Environment/Architecture 


Figure  7  depicts  the  RHS  operational  environment.  It  gives  a  breakdown  at  a 
more  granular  level  than  the  MPTE  system  overview  described  in  the  MPTE  section. 
Additionally,  it  filters  out  any  of  the  functional  areas  and  interfaces  that  do  not  directly 
affect  the  RHS.  What  is  shown  in  Figure  7  is  that  the  RHS  interfaces  directly  with  15 
other  applications — either  providing  information  to  them,  extracting  information  from 
them,  or  both.  A  detailed  breakdown  of  these  interfaces  follows  this  section.  Here,  the 
figure  is  given  to  create  a  visual  representation  of  the  RHS  to  enhance  the  readers’ 
understanding  of  the  application.  In  conjunction  with  Figure  4,  Figure  7  allows  one  to 
visually  investigate  the  RHS  application  level  while  keeping  in  mind  the  overall  system 
picture. 
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Figure  7.  The  Reserve  Headquarters  Support  System  (From  Bergeron,  2008,  slide  5) 
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Based  upon  information  gathered  from  the  RHS  system  owners  at  SSC  NOLA 
and  the  RHS  System  Overview  presentation  given  by  the  Program  Manager,  Mr.  Kelly 
Bergeron  (2008),  the  RHS  application  leverages  the  following  hardware  and  software: 

Platform:  HP  AlphaServer  ES40  Cluster 

Operating  System:  Open  VMS 

Application  S/W:  VAX  BASIC,  SmartStar,  SQL,  DCL 

Database  Management  System:  Oracle  9.2. 0.8.0 

The  physical  location  for  these  assets  is  currently  the  SPAWAR  Systems  Center 
New  Orleans  (SSC  NOLA),  with  a  co-operating  site  in  San  Diego,  CA. 

Combined,  these  assets  support  roughly  290  interactive  users  and  400-plus  Navy 
Echelon-five-level  batch  accounts  through  the  Navy  Standard  Integrated  Personnel 
System  (NSIPS).  Echelon  five  refers  to  the  level  in  the  Navy  organization  at  which  these 
transactions  take  place;  i.e.,  they  take  place  five  layers  down  from  the  top.  In  total,  69 
million  transactions  are  conducted  and  handled  per  month  on  the  RHS  application. 

As  stated  above,  the  RHS  application  hardware  and  software  is  physically  located 
and  maintained  in  New  Orleans,  LA,  at  SSC  NOLA.  Figure  8  gives  a  view  of  the  logical 
flow  of  data  from  the  RHS  to  the  Navy  Personnel  database  (NPDB),  which  is  located  in 
Mechanicsburg,  PA. 
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Figure  8.  Data  Flow  Between  Navy  Systems  (From  Murphy,  2007,  slide  47) 


As  depicted  in  the  NOLA  box  in  Figure  8,  NSIPS  (which  is  a  PeopleSoft-based 
application)  provides  both  database  functionality  and  serves  as  the  front-end  interface  for 
data  input.  Through  its  interface  to  the  RHS,  it  is  used  to  conduct  pay  and  personnel 
actions  for  Navy  Reserve  personnel  (JR&IO,  2004).  NSIPS  is  used  in  the  field  by 
personnel  professionals  at  Navy  Reserve  Activities  (NRA)  and  Navy  Operational  Support 
Centers  (NOSC)/fonnerly  Naval  Reserve  Centers.  Additionally,  “At  the  corporate  level, 
Navy  Personnel  Data  Base  (NPDB),  OPINS,  NES,  IMAPMIS,  RFIS,  and  Navy  Military 
Personnel  Data  System  (NMPDS)  provide  manpower,  personnel  and  pay  management 
support”  (JR&IO,  2004,  p.  9).  NPDB  is  the  integrator  database  for  all  Navy  personnel 
(active  and  inactive);  however,  the  data  stored  in  NPDB  is  limited  and  does  not  contain 
exhaustive  personnel  information  for  each  personnel  account.  Finally,  as  the  process 
exists  today,  “Reserve  management  information  is  provided  via  data  transfer  or  hard  copy 
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reports  to  Reserve  field  activities,  Reserve  Headquarters,  BUPERS,  Chief  of  Naval 
Personnel,  Secretary  of  the  Navy  (SECNAV),  OSD,  and  other  DoD  activities”  (JR&IO, 
2004,  p.  10). 

4.  RHS  Interfaces 

The  RHS  contains  15  interfaces  and  processes  over  750,000  transactions  per 
month  from  Navy  Reserve  field  activities — including  over  300,000  pay  transactions  that 
provide  $35  million  a  month  in  reserve  pay  (Murphy,  2007). 

The  following  list  highlights  a  few  of  the  more  important  system  interfaces  and 
their  functions: 

•  NSIPS,  IMAPMIS  and  DJMS-RC — personnel  and  pay 

•  TFMMS — manpower  requirements  data,  reserve  billet  data,  and 
headquarters-level  support  for  force  billet  and  mobilization  management 

•  NSIPS — Three  daily  transmissions  and  feedback 

•  DJMS-RC — Daily  transmissions  of  direct  pay  data 

•  IMAPMIS — Daily  pay  and  personnel  data  that  require  Navy  corporate 
system  interface  affecting  transmissions  being  fed  back  to  the  RHS  and  on 
to  DJMS-RC. 

•  RSTARS-HP — Supports  DJMS-RC  pay  processing  interfaces  for  Health 
Professions  Scholarship  participants  via  Reserve  Standard  Training 
Administration  and  Readiness  Support  for  Health  Professions  (RSTARS- 
HP)  (JR&IO,  2004,  p.  1 1). 

Finally,  Table  1  provides  an  exhaustive  list  of  RHS  interfaces,  including  data  flow 
direction,  interface  type,  and  purpose  of  the  interface. 
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Table  1.  RHS  Interfaces  (After  Bergeron,  2008,  slide  3) 


INTERFACES: 

SSC  NOLA  SYSTEMS 

Data  flow 

System  Name 

Interface  Type 

Purpose 

To 

OPAS 

FTP  Batch 

Reserve  Officer  data 

To 

NTRS 

FTP  Batch 

Reserve  Personnel  data 

ToFrom 

TFMMS 

FTP  Batch 

Billet  requirements 

To  From 

RSTARS  (HP) 

FTP  Batch 

Student  PERS  PAY  data 

To 

MRRS 

SQLNET 

Reserve  Personnel  data 

To  From 

RIMS  (FM) 

FTP  Batch 

Reserv  e  Bonus  data 

ToFrom 

NROWS 

SQLNET  and  FTP 

Reserve  Pers  and  Order  data 

ToFrom 

IMAPMIS 

FTP  Batch 

Reserve  Pers  and  Pay  data  (inc  IRR) 

To 

CMS 

FTP  Batch 

Reserve  Personnel  data 

External  Systems 

Data  flow 

System  Name 

Purpose 

ToFrom 

DJMS-RC 

FTP  Batch 

Reserve  Pers  and  Pay  data 

From 

DJMS-CL 

FTP  Batch 

Reserve  Pers  and  Pay  data 

ToFrom 

NSIPS 

SQLNET  and  FTP 

Reserve  Pers  and  Pay  data 

To 

NMCMPS 

FTP  File  Batch 

Reserve  Pers  and  Mob  data 

To 

CNRF  Staging 

FTP 

Pers  Billet  Mob  Unit  data 

To 

CNRF  N6  Data  Warehouse 

FTP 

Pers  Billet  Mob  Unit  data 

For  more  details  on  the  RHS  application,  including  system  statistics,  interface 
statistics,  and  interface  descriptions,  see  Appendix  A. 

5.  Issues  with  the  Current  System 

When  the  Cost  Governance  Model  was  completed  by  SSC  NOLA  staff  in 
February  of  2008,  an  ominous  tone  was  set  concerning  the  RHS  application.  According 
to  the  study,  the  RHS  is  at  risk  of  being  shutdown  due  to  non-compliance  with  DoD  and 
DoN  Information  Assurance  requirements;  a  technical  re-engineering  must  be  completed 
within  the  next  couple  of  years.  Additionally,  this  study  asserted  that  the  RHS  system  is 
in  jeopardy  of  a  complete  system  failure  due  to  age-related  issues — such  as  the  inability 
to  get  replacement  hardware  parts,  the  aging  of  the  software,  and  the  lack  of  experienced 
people  to  work  on  it  (Robertson,  2008).  The  issues  facing  the  RHS  are  complex.  Thus, 
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the  focus  of  this  section  will  be  on  issues  concerning  the  system’s  underlying  technology 
(including  interfaces  and  processes),  system  support,  architecture,  and  budgetary 
constraints. 


6.  Technology 

In  a  Statement  of  Objectives  document  completed  by  the  MPTE  code  N16  (Chief 
Information  Officer),  an  Enterprise  Data  Environment  (EDE)  proof  of  concept  pilot 
program  is  proposed  (Navy  MPTE,  2008).  Within  that  document,  requirements  are 
described  that  must  be  met  to  ensure  that  migration  to  an  EDE  can  be  met.  By  reading 
these  system  requirements,  one  can  see  that  some  deficiencies  within  the  current  MPTE 
environment  create  issues  for  such  a  migration.  In  particular,  some  of  these  deficiencies 
can  be  attributed  to  the  RHS  itself.  Some  of  these  issues  or  deficiencies  include: 

•  Identification  of  authoritative  data  has  not  been  completed.  This  issue 
needs  to  be  addressed  regardless  of  whether  the  RHS  application  is  re¬ 
written. 

•  Non-authoritative  data  has  not  been  eliminated.  This  issue  is  related  to  the 
prior  issue  in  that,  once  authoritative  data  is  identified,  by  default,  non- 
authoritative  data  is  also  identified.  This  issue  is  critical  to  address  so  that 
unnecessary  data  is  not  included  in  restructuring  efforts  and  so  that 
inefficiencies  associated  with  storing,  maintaining,  and  processing  such 
data  are  eliminated. 

•  System  documentation  has  not  been  kept  up-to-date.  This  leads  to  several 
issues,  including  a  lack  of  understanding  of  the  current  environment  and 
an  inability  to  trace  its  structure  and  functionality. 

•  Domain  mission-critical  processes  have  not  been  identified.  Just  as  with 
the  lack-of-documentation  issue,  without  clear  delineation  of  what  the 
critical  system  functions  are,  change  potential  is  limited. 

•  Data  dictionary  artifacts  have  not  been  identified.  To  understand  how  to 
improve  the  system,  system  owners  must  understand  what  the  critical 
processes  are  and  then  identify  the  critical  data  that  supports  these 
processes.  At  the  time  of  this  writing,  the  author  had  made  unsuccessful 
attempts  to  acquire  a  copy  of  system  data  dictionaries  from  the  RHS 
system  owners. 

•  Supporting  system  data  elements  have  not  been  identified.  This  issue  is 
associated  with  the  multiple  system  interfaces  that  are  maintained  within 
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the  RHS.  If  system  owners  do  not  have  a  clear  understanding  and 
documentation  of  system-to-system  dependencies,  data  errors  will 
continue  when  changes  are  made  to  either  the  RHS  or  interfaced  systems. 

•  A  defined  change  process  has  not  been  designed.  As  system  owners  do 
not  clearly  understand  system  dependencies,  at  present  it  is  difficult  (at 
best)  for  system  designers  to  put  in  place  any  process  that  will  coordinate 
changes  among  interfacing  systems.  This  limitation  creates  an 
environment  in  which  changes  are  made  and  placed  into  production.  When 
problems  arise,  there  are  several  possible  courses  of  action:  a  successful 
firelight  ensues  that  either  repairs  the  interface,  or  the  change  is  required 
to  be  backed  out,  or  the  system  is  reverted  to  its  original  state. 

As  discussed  so  far,  the  issues  pointed  out  are  of  both  a  technical  and  procedural 
nature.  Now,  we  will  examine  some  of  the  specific  technical  challenges  the  RHS  faces. 

7.  Interfaces 

As  with  many  major  systems,  the  RHS  system  is  composed  of  interfaces  between 
systems  that  have  different  data  structures.  This  complexity  allows  for  mutually 
beneficial  relationships  for  the  associated  business  system  owners  and  is  necessary  to 
conduct  business  and  to  comply  with  applicable  regulations,  among  other  benefits.  The 
issue  at  hand  is  not  in  removing  interfaces,  which  would  have  the  effect  of  removing 
functionality  and/or  putting  the  system  in  a  state  of  non-compliance;  instead,  the  issue  is 
that  the  RHS  does  not  have  the  basic  building  blocks  in  place  for  it  to  continue 
conducting  business  long  into  the  future.  Many  of  the  above-discussed  problems  are 
impacted  by  or  impact  the  RHS.  Namely,  the  data  quality  within  the  RHS  is  not  as  high 
it  needs  to  be,  nor  are  the  processes  and  procedures  for  interfacing  with  other  systems 
clean  and  clear  enough. 

8.  Work-around  Processing 

Over  the  years,  complex  work-around  logic  has  been  built  into  the  RHS  so  it  can 
continue  conducting  business  as  usual.  These  business  continuation  processes  have  been 
necessitated  by  changes  to  the  RHS  and  changes  to  the  systems  with  which  it  interfaces. 
These  changes  include  things  such  as  the  ability  to  accept  new  file  formats  from  other 
systems,  to  create  custom  files  that  will  be  useable  by  receiving  systems,  and  to  deal  with 
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new  security  requirements.  Much  of  the  logic  built  into  the  application  is  complex  and 
poorly  documented.  This  poor  documentation  creates  enormous  risk  for  the  health  of  the 
system  going  forward.  If  the  programmers  associated  with  many  of  these  changes  were 
to  leave,  support  of  the  as-is  system  would  become  more  complex.  This  problem  is 
compounded  by  the  fact  that  documentation  is  inadequate  to  be  of  use  to  any  new 
programmers.  However,  since  the  RHS  is  confined  to  the  constructs  under  which  it  was 
initially  built,  the  problem  of  work-around  process  will  be  with  the  system  until  major  re¬ 
engineering  efforts  begin. 

9.  Support 

Production  support  for  the  RHS  is  becoming  increasingly  complex  for  many  of 
the  reasons  already  stated.  Most  of  these  support  issues  are  due  to  the  age  of  the  system, 
the  structure  (architecture),  the  number  of  interfaces,  and  poor  documentation. 
According  to  Captain  Bill  Camey,  Commander  Navy  Reserve  Forces  Command 
(CNRFC)  Deputy  Chief  Information  Officer  (N6a)  (B.  Carney,  personal  communication, 
December  17,  2008),  and  Kelly  Bergeron,  SSC  NOLA  RHS  Technical  Lead  (K. 
Bergeron,  personal  communication,  December  18,  2008),  the  key  areas  of  concern 
regarding  the  support  of  the  RHS  are:  maintenance,  upgradability  and  system 
performance.  These  are  common  difficulties  in  systems  as  old  as  RHS.  These  experts 
further  described  how,  over  its  lifetime,  the  application  has  incurred  several 
modifications  that  have  adversely  affected  perfonnance,  reliability,  and  accuracy. 
Additionally,  the  architecture  is  cluttered  with  excessive  interfaces  to  other  systems  (each 
requiring  code  to  be  written  and  maintained)  that  have  created  difficulties  in  documenting 
the  current  state  of  the  system.  Adding  to  the  system  difficulties  is  the  fact  that  many 
changes  have  been  made  hastily  without  proper  documentation  by  the  technicians  who 
maintain  them.  Therefore,  in  the  future,  changes  to  the  system  will  require  extensive 
system  experience  due  to  its  complexity  and  lack  of  documentation.  This  leads  to 
another  problem:  a  lack  of  trained  professionals  (both  at  SSC  NOLA  and  in  the  IT 
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industry  at  large)  familiar  with  the  older  technologies  upon  which  the  RHS  is  built.  In 
addition  to  the  aforementioned  support  issues,  the  RHS  suffers  from  funding  issues  that 
we  will  investigate  next. 

10.  Cost/Funding/Acquisition  Issues 

One  of  the  central  issues  concerning  funding  is  that  the  RHS  has  only  been  funded 
at  the  Operations  and  Maintenance  (OM&N)  level  for  the  past  several  years.  The 
application  has  received  no  Research  and  Development  (R&D)  funding  with  which  to 
improve  its  underlying  architecture  and  explore  feasible  long-term  solutions. 
Additionally,  RDT&E  funding  has  been  put  on  hold  until  decision-makers  resolve  the 
Defense  Integrated  Military  Human  Resource  System  (DIMHRS).  Also,  OM&N  funds 
have  been  at  the  minimum  level  to  run  the  business  for  the  past  several  years;  only 
mission-critical  functions  are  being  supported.  The  following  table — taken  from  the 
POM  10  PEO  EIS  briefing  (Murphy,  2007) — shows  the  funding  status  of  the  RHS. 
Interestingly,  for  FY08  and  FY09,  only  OM&N  funding  was  approved  for  system 
support.  However,  this  problem  has  been  addressed  in  that  for  FY  10  through  FY  13, 
both  OM&N  and  RDT&E  funding  have  been  proposed  for  budget  approval.  The  addition 
of  RDT&E  funding  is  to  position  RHS  to  be  ready  for  migration  to  the  DIMHRS.  Tying 
the  RDT&E  funds  to  the  migration  effort  creates  an  issue  if  the  DIMHRS  is  not 
successful.  These  funds  need  to  be  approved  regardless  of  what  platfonn  the  RHS  will 
eventually  migrate  to  because  if  they  are  not,  the  problems  that  we  have  described  in  this 
chapter  will  only  get  worse. 


Table  2.  Funding  for  the  RHS  (From  Murphy,  2007,  slide  30) 
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RHS  is  not  the  only  system  that  is  experiencing  accelerating  problems.  We  will 
now  turn  our  attention  to  some  of  the  other  systems  that  are  facing  similar  issues  that 
need  to  be  fixed  for  an  eventual  move  to  a  more  seamless  Navy  enterprise  IT 
environment. 

11.  Other  Systems  to  Keep  in  Mind 

If  changes  to  the  RHS  are  to  be  successful,  at  minimum  those  applications  within 
its  functional  area  (Personnel- Authoritative  Forces)  must  be  studied  to  ensure  that  they 
will  not  only  continue  to  operate  together,  but  also  will  offer  more  robust  functionality 
going  forward.  Agreed-upon  standards  will  need  to  be  communicated  and  met  so  the 
RHS  will  be  able  to  seamlessly  transition  to  the  new  state  without  disrupting  its 
interfaces.  Ultimately,  the  other  applications  within  this  functional  domain — Navy 
Enlisted  System  (NES),  Officer  Personnel  Information  System  (OPINS),  Navy  Standard 
Integrated  Personnel  System  (NSIPS),  and  Inactive  Manpower  and  Personnel 
Management  Infonnation  System  (IMAPMIS) — will  need  to  undergo  changes  similar  to 
the  RHS  to  ensure  future  compatibility  and  greater  functionality. 

The  following  points  taken  directly  from  the  POM  10  PEO  EIS  briefing  (Murphy, 
2007)  highlight  some  of  the  issues  facing  the  aforementioned  systems  and  the  associated 
consequences  of  not  proactively  addressing  them.  For  clarity,  PERSYS  is  comprised  of 
NES,  OPINS  and  NSIPS,  as  well  as  other  smaller  systems. 

•  Operational  Risk  (High):  PERSYS  has  NO  “in-Core”  funding  in  FY10  and 
beyond.  If  the  systems  are  shut  down  because  of  a  lack  of  funding,  Active 
Duty  Navy  personnel  pay  will  be  severely  impacted,  and  the  Navy  will  not 
be  able  to  effectively  manage  its  personnel. 

•  Future  Challenges  (High):  Given  the  precarious  state  of  readiness  and  the 
unparalleled  efforts  of  the  Navy  in  retaining  more  capable,  more 
experienced,  more  technical  workforce,  reductions  to  PERSYS  now  or  in 
the  future  across  the  FYDP  will  lead  to  critical  failure.  The  resources 
allocated  to  PERSYS  in  future  FYs  must  be  restored.  [Rjecent  cuts  will 
not  only  impair  readiness  and  retention,  but  will  impact  the  ability  to 
support  migration  to  the  DIMHRS  and  to  develop  Navy-unique 
functionality  that  will  not  exist  in  the  DIMHRS. 

•  Cons:  If  PERSYS  is  not  funded,  the  systems  will  be  shut  down,  and  the 
Navy  will  be  unable  to  pay,  promote,  and  retire  sailors.  (Murphy,  2007) 
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This  chapter  has  indicated  that  the  RHS  is  not  alone  in  the  issues  it  faces.  What  is 
clear,  however,  is  that  any  efforts  to  make  the  RHS  better  must  be  conducted  in  concert 
with  other  initiatives  taking  place  within  the  Navy  enterprise.  Now  that  the  current  states 
of  the  IT  systems  relative  to  this  study  have  been  examined,  the  next  chapter  will  address 
the  proposed  state  of  these  systems,  with  particular  emphasis  on  the  RHS. 
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III.  DESIRED  STATE  OF  INFORMATION  SYSTEMS 


A.  DEPARTMENT  OF  DEFENSE  (DOD)  VISION 

Some  believe  that  with  the  United  States  in  the  midst  of  a  dangerous  war 
on  terrorism,  now  is  not  the  time  to  transform  our  armed  forces.  I  believe 
that  the  opposite  is  true.  Now  is  precisely  the  time  to  make  changes.  The 
war  on  terrorism  is  a  transformational  event  that  cries  out  for  us  to 
rethink  our  activities,  and  to  put  that  new  thinking  into  action. 

Secretary  of  Defense  Donald  H.  Rumsfeld 
Transformation  Planning  Guidance,  April  2003 

The  DoD  is  continuing  with  many  facets  of  organizational  transformation  that  the 
former  Secretary  of  Defense  described.  This  change  is  far  reaching — to  include 
operations  related  to  conducting  warfare,  acquiring  weapon  systems,  resourcing  force 
structure,  and  designing  business  processes.  In  this  chapter,  the  focus  is  on  business 
processes  and  force  structure  as  related  specifically  to  Human  Resources  Management 
(HRM).  It  begins  by  examining  the  vision  of  the  DoD  in  relation  to  HRM,  followed  by  a 
discussion  of  how  this  vision  is  to  be  carried  out  within  the  Department  of  the  Navy 
(DoN),  and  finally  concludes  with  a  discussion  of  how  this  vision  will  be  carried  out  in 
relation  to  the  Commander  Navy  Reserve  Forces  (CNRF)  HRM  system  Reserve 
Headquarters  Support  (RHS). 

1.  Force  Integration 

Ultimately,  the  goal  of  the  DoD — the  defense  of  our  nation — has  remained 
constant  over  time.  However,  the  nature  of  the  environment  has  changed,  necessitating  a 
shift  in  culture  and  practice  from  a  Cold  War-oriented  force  to  one  that  can  better  deal 
with  the  complexities  of  the  current  post-Cold  War  era.  The  Cold  War  organizational 
force  structure  can  be  described  as  a  machine  bureaucracy — an  organizational 
configuration  described  by  Henry  Mintzberg.  Machine  bureaucracies  are  structured  in  a 
highly  hierarchical  fashion,  as  is  the  DoD.  In  the  Post-Cold  War  environment,  the 
effectiveness  of  this  structure  is  questionable.  The  nature  of  our  nation’s  defense  has 

33 


changed  due  to  the  changing  face  of  our  real  and  potential  adversaries.  This  shift  has 
required  that  DoD  components  adopt  more  flexible  structures  that  will  enable  stronger 
relationships  between  the  DoD  components.  In  relation  to  HRM,  this  shift  can  be  seen  in 
the  following  passage  from  an  article  concerning  Global  Force  Management  (GFM). 
“USJFCOM  relies  heavily  on  its  Service  components  to  coordinate  with  the  Service 
headquarters  and  other  combatant  command  Service  components  to  track  capabilities  and 
forces  in  order  to  assess  operational  readiness,  availability,  commitment,  and  capability 
substitution  options”  (Ferriter  &  Burdon,  2007,  p.  46).  To  enable  this  type  of 
coordination  efficiency,  the  DoD  must  transfonn  the  way  it  conducts  its  business.  A  large 
part  of  this  transformation  will  be  enabled  by  a  re-tooling  of  its  business  processes.  To 
this  end,  the  DoD  established  the  Business  Transformation  Agency  (BTA)  in  October 
2005  and  announced  its  organizational  structure  in  February  2006. 

2.  Business  Applications  and  the  Business  Transformation  Agency 
(BTA) 


a.  Defense  Integrated  Military  Human  Resource  System 
(DIMHRS) 

The  BTA  is  tasked  with  transforming  the  business  operations  of  an 
organization  that  employs  three  million  personnel  (uniformed  and  civilian)  throughout 
the  world  into  an  organization  that  can  meet  the  complex  requirements  of  the  current 
environment  (OMB,  2009).  As  per  the  official  BTA  Web  site  (BTA,  2009c),  the 
Transformation  Priorities  and  Requirements-HRM  Directorate  serves  as  the  primary  link 
to  the  Office  of  the  Undersecretary  of  Defense  (Personnel  and  Readiness)  (OUSD 
(P&R)).  The  primary  products  and  guidelines  produced  by  the  BTA  enabling  HRM  are 
the  focus  of  the  next  section  of  this  paper. 

b.  Business  Transformation  Agency  Products 

The  DoD  expects  that  ultimately,  under  the  direction  of  the  BTA, 
personnel-related  IT-system  issues  will  be  resolved  by  implementing  the  Defense 
Integrated  Military  Human  Resource  System  (DIMHRS).  This  solution  will  be  phased  in 
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starting  with  the  uniformed  Armed  Services,  and  will  ultimately  be  utilized  by  all  of  the 
organizational  components  within  the  DoD.  The  military  implementation  is  expected  to 
benefit  Service  members  and  their  families  by  “Integrating  personnel  and  pay  for  all 
service  members  into  a  single  system  [that]  will  ensure  they  are  paid  accurately  and  on 
time”  (ROA  of  the  U.S.,  2009).  Further,  “With  a  single  record  of  service  and  integration 
across  all  uniformed  services  and  Active,  Reserve,  and  Guard  Components,  transfers 
between  components  and  across  the  services  will  be  seamless.  The  DIMHRS  also  will 
allow  commanders  to  track  personnel  regardless  of  location  or  branch  of  service  and 
ensure  the  right  people  are  in  the  right  place  at  the  right  time”  (ROA  of  the  U.S.,  2009,  p. 
1).  Finally,  as  the  DIMHRS  is  a  Web-based  application,  it  follows  that,  “essential 
personnel  records  will  be  instantly  available  to  human  resources  specialists,  commanders, 
personnel  and  pay  managers,  and  other  authorized  users”  (ROA  of  the  U.S.,  2009,  p.  1). 
This  assertion  assumes  that  connectivity  issues  will  be  mitigated. 

3.  Guidelines  and  Enablers  to  Achieve 

Whether  or  not  the  DIMHRS  is  successfully  completed  and  installed,  the  direction 
from  the  DoD  remains  the  same:  that  its  personnel  systems  must  be  upgraded  to  keep 
pace  with  changing  operational  requirements  and  technology.  To  meet  these  more 
general  requirements  as  they  relate  specifically  to  HRM,  the  BTA  (through  the 
Transformation  Priorities  and  Requirements-HRM  Directorate)  “ensures  that  the 
functional  priorities  and  requirements  of  the  client  organizations,  as  well  as  those  of  the 
Services  and  Agencies,  are  accurately  reflected  in  both  the  Business  Enterprise 
Architecture  (BE A),  the  Enterprise  Transition  Plan  (ETP)  and  the  guidance  provided  for 
business  system  investment  review”  (BTA,  2009c,  p.  1).  A  short  discussion  of  these 
elements  follows. 


a.  Business  Enterprise  Architecture  (BEA) 

In  March  of  2009,  the  BTA  released  Version  6.0  of  the  BEA,  which  is  a 
comprehensive  guide  for  transfonning  the  business  practices  of  the  DoD.  The  BEA 
provides  high-level  documentation  and  guidance  for  the  enterprise  on  the  theories  and 
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methodologies  that  are  to  be  applied  to  ensure  a  successful  transition.  The  BE  A  Web  site 
contains,  “a  virtual  ‘Center  of  Excellence’  and  is  a  useful  resource  for  people  interested 
in  developing  architecture  or  understanding  Service  Oriented  Architecture  (SOA)  and 
federation  concepts”  (BTA,  2009a,  p.  1).  For  components  and  organizations  that  require 
transfonnation,  such  as  the  OUSD  (P&R)  and  the  Navy,  the  BEA  is  the  ultimate  source 
for  the  definition  of  requirements,  guidelines,  and  procedures  to  which  DoD  agencies 
must  adhere.  Finally,  “The  BEA  consists  of  a  set  of  integrated  architecture  framework 
products  that  define  operational  activities,  process  data,  information  exchanges,  business 
rules,  system  functions,  system  data  exchanges,  terms  and  linkages  to  laws,  regulations 
and  policies  associated  with  the  Department’s  business  operations”  (BTA,  2009a,  p.  1). 

b.  Enterprise  Transition  Plan  (ETP) 

In  conjunction  with  the  BEA,  the  ETP  provides  greater  granularity  and 
guidance  for  the  DoD  and  is  the  roadmap  to  be  followed  concerning  the  business 
enterprise  architecture.  According  to  the  ETP  Web  site  (BTA,  2009b),  the  following  list 
defines  the  scope  of  this  plan: 

•  The  acquisition  strategy  for  new  systems  that  make  up  the  target  enterprise 
architecture, 

•  A  listing  of  defense  business  legacy  systems  not  expected  to  be  part  of  the 
target  environment  (as  of  2002), 

•  A  list  of  the  defense  business  legacy  expected  to  be  part  of  the  target 
environment,  and 

•  Time-phased  milestones,  performance  metrics  and  a  statement  of  the 
financial  and  non-financial  resource  needs.  (2009b,  p.  1) 

The  DIMHRS  fits  under  the  first  bullet,  while  the  next  three  bullets 
directly  relate  to  the  focus  system  of  this  paper,  the  Reserve  Headquarters  Support 
(RHS).  In  the  ultimate  vision  of  the  future  business  enterprise,  the  RHS  will  not  be 
included,  as  it  will  be  subsumed  by  the  DIMHRS.  However,  prior  to  meeting  this  goal,  it 
will  be  important  for  the  RHS  owners  to  position  the  application  for  such  a  transition  by 
modernizing.  Therefore,  it  will  be  prudent  and  necessary  for  the  RHS  to  follow  the 
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roadmap  provided  by  the  ETP  to  ensure  a  smooth  transition.  Figure  9  from  the  ETP 
gives  a  concise  representation  of  how  the  DoD  components  are  integrated  within  the 
enterprise.  The  RHS  fits  within  the  Navy  component. 


Figure  9.  DoD  Enterprise  Capabilities  by  Component  (From  BTA,  2009e,  p.  4) 


Finally,  the  ETP  is  focusing  on  six  business  priorities  to  guide  the  DoD 
enterprise  transformation — including  Personnel  Visibility  (PV),  Acquisition  Visibility 
(AV),  Common  Supplier  Engagement  (CSE),  Materiel  Visibility  (MV),  Real  Property 
Accountability  (RPA),  and  Financial  Visibility  (FV).  The  focus  of  this  paper  is  on  PV — 
which,  in  the  latest  version  of  the  ETP  (September  2008),  is  described  as  “the  fusion  of 
accurate  human  resources  (HR)  information  and  secure,  interoperable  technology  within 
the  Human  Resources  Management  (HRM)  Core  Business  Mission  (CBM)”  (BTA, 
2009e,  p.  35).  As  such,  the  DIMHRS  falls  under  PV,  and  by  default,  so  does  the  RHS. 

c.  Business  System  Investment  Review  Guidance 

The  final  guidance  from  the  BTA  that  this  paper  will  explore  is  the 
Investment  review  Board  (IRB)  Process.  “The  process  is  guided  by  the  BEA  and  the 
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Enterprise  Transition  Plan  (ETP),  which,  along  with  related  Component  architectures  and 
transition  plans,  provides  an  integrated  view  of  business  functions  and  a  roadmap  for 
more  robust  business  capabilities”  (BTA,  2009d).  Important  to  the  transition  of  RHS  is 
the  fact  that  once  the  transition  process  is  underway,  it  will  be  monitored  for  progress  and 
compliance  via  an  annual  review.  This  review  is  applied  to  business  systems  that  have  no 
dedicated  modernization  funding.  The  RHS  falls  into  this  category  because  funding  for 
modernization  is  being  directed  to  the  DIMHRS  and  not  to  systems  that  the  DIMHRS 
will  subsume.  Figure  10  shows  how  the  concepts  described  in  this  section  (PV,  the  BEA, 
the  ETP,  and  Business  Investment  Review)  fit  into  the  overall  DoD  enterprise  plan. 
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Figure  10.  The  Path  to  DoD-wide  Business  Agility  and  Information  Visibility 

(From  BTA,  2009d,  p.  3) 


Next,  we  will  examine  the  OUSD  (P&R)  in  relation  to  the  initiatives  it  is 
working  on  in  order  to  meet  the  goals  of  the  BTA  and  the  DoD. 
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4. 


Office  of  the  Under  Secretary  of  Defense — Personnel  and  Readiness 
(OUSD  (P&R)) 


Within  the  OUSD  (P&R),  the  Human  Resource  Management  Enterprise 
Architecture  (HRM  EA)  Division  “coordinates  the  implementation  of  Department  of 
Defense  Architecture  Framework  (DoDAF)  architecture  methodologies  to  develop  HRM 
business  area  architecture”  (P&R  IM,  2009,  p.  1).  Implementation  efforts  are  conducted 
in  concert  with  BTA  efforts,  and  both  efforts  support  one  another.  More  precisely,  the 
efforts  of  the  OUSD  (P&R)  directly  support  the  enterprise  transfonnation  efforts  of  the 
BTA  described  above.  The  following  description  from  the  OUSD  (P&R)  Web  site 
further  illustrates  the  ties  between  the  BTA  and  the  OUSD  (P&R):  the  “HRM  EA 
Division  Chief  acts  as  the  advisor  for  HRM  business  architecture  and  the  liaison  for 
HRM  Lines  of  Business  capabilities  and  architecture  efforts  within  DoD,  coordinating  the 
development  of  HRM  architecture  for  the  Business  Enterprise  Architecture  (BEA).” 
Further,  the  “HRM  Enterprise  Architecture  Division  Chief  provides  authoritative 
interpretations  of  HRM  federation  and  architecture  integration  issues  within  the  DoD 
HRM  community”  (P&R  IM,  2009,  p.  1).  This  direction  comes  from  the  DoD  level  to 
the  component  level,  and  ultimately  will  drive  and  govern  the  re-engineering  efforts  of 
the  RHS. 

The  Operational  Vision  (OV)  of  the  HRM  EA  is  depicted  in  Figure  11.  This 
graphic  gives  a  visual  representation  of  the  functions  that  are  to  be  encompassed  in  any 
Human  Resource  IT  application  development.  Specifically,  these  are  the  functions  the 
DIMHRS  must  cover.  As  such,  any  development  efforts  short  of  or  in  support  of  the 
DIMHRS  must  be  built  with  these  functions  or  include  a  pertinent  subset  of  them. 
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Changing  the  way  HR  serves  you 


Figure  11.  OV-1:  DoD  Personnel  and  Pay:  High-level  Operational  Concept  Description 

(From  DoN  HCS,  2009) 

B.  DEPARTMENT  OF  THE  NAVY  (DON) 

In  line  with  the  DoD  strategy  to  implement  the  DIMHRS  as  the  sole  personnel 
and  pay  system  used  by  the  Department,  the  DoN  has  agreed  to  migrate  to  this  solution  in 
the  future.  The  Federal  Computer  Week  Web  site  summed  up  the  progress  for  the 
migration  as  follows,  “The  Navy  and  Marine  Corps  will  move  to  the  Defense  Integrated 
Military  Human  Resources  Systems  (DIMHRS)  after  all — but  no  one  is  sure  when” 
(Miller,  2007,  p.  1).  Regardless  of  the  outcome  of  DIMHRS  implementation  efforts,  the 
“DoN  is  rapidly  moving  away  from  a  vertical  (command  and  control)  model  to  a 
horizontal  (connect  and  collaborate)  model”  (ASN  (M&RA),  2009,  p.  4).  In  regards  to 
the  complexities  of  transitioning  from  a  vertical  to  a  horizontal  model,  the  following 
assessment  was  made  in  the  DoN  DIMHRS  Concurrent  Review: 
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[Tjhere  is  still  a  long  way  to  go.  Our  family  of  systems  must  be  opened  so 
as  to  include  both  DON  civilian  employees  and  contractors  into  our 
workforce  planning  processes.  Many  of  our  civilian  employees  and 
contractors  are  also  reservists.  The  DON  can  no  longer  afford  to  maintain 
this  data  in  stand-alone  systems.  To  solve  this  problem,  the  department  is 
establishing  standards  for  content,  accuracy,  and  interchangeability. 

These  same  standards  are  the  method  by  which  DON  systems  will  become 
an  integral  part  of  a  new  Defense  Integrated  Human  Resource 
Management  Information  System — all  while  meeting  the  objective  of  the 
Business  Management  Modernization  Program  (BMMP)  to  gain 
efficiency  along  the  way.  (ASN  (M&RA),  2009,  p.  4,  emphasis  in 
original) 

The  review  further  asserts  that  successful  modernization  will  be  enabled  by 
“pursuing  open  system  standards  and  data  warehouse  technology,”  with  which  the  “DON 
will  not  only  be  able  to  meet  the  current  joint  and  COCOM  needs,  but  quickly  adapt  to 
future  requirements  as  well”  (ASN  (M&RA,  2009,  p.  4). 

From  the  PEO  EIS,  Figure  12  depicts  the  DoN  corollary  to  the  DoD  OV-1  shown 
in  the  prior  section  concerning  the  OUSD  (P&R).  It  is  shown  here  to  logically  illustrate 
the  flow  of  requirements  at  the  various  levels  within  the  DoD.  The  Department  of  the 
Navy  Human  Capital  Strategy  articulates  the  components  of  this  high-level  model  as  four 
Systems-focused  Strategic  Goals:  Recruit/Access,  Manage,  Force  Shaping,  and 
Separate/Retire.  Further,  it  explains,  “All  DoN  activities  involving  people  will  be  linked 
and  aligned.  The  system  must  be  transparent  and  permit  people  to  move  back  and  forth 
between  components  and  workforce  categories.  Authority  and  accountability  for  the 
performance  of  the  process  will  be  vested  in  a  process  owner”  (ASN  (M&RA),  2004,  p. 
15). 
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Figure  12.  DoN  FIRM  OV-1  in  Support  of  DoD  OV-1 
(From  DoN  HCS,  2009a) 


Additional  guidance  is  provided  by  the  Force  Management  Oversight  Council 
(FMOC)  and  is  reflected  in  the  Department  of  the  Navy  Human  Capital  Strategy  of  June 
2004.  In  this  document,  the  ASN  (M&RA)  describes  the  FMOC’s  requirement  to  create 
a  Total  Workforce  Management  (TWM)  solution.  TWM  will  “achieve  an  integrated 
personnel  system  of  active  and  reserve  military,  civilians,  contractors,  and  volunteers, 
and  also  [explain]  how  to  provide  portability  and  flexibility  in  utilization  of  all  workforce 
members,  as  well  as  flexible  career  lengths  and  patterns  of  service  for  the  military”  (ASN 
(M&RA),  2004,  p.  16).  In  addition  to  these  DoN  goals,  Joint  Force  Management  will 
also  need  to  be  met  in  the  future,  providing  the  same  set  of  functions  in  a  joint 
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environment.  All  of  these  functions  will  need  to  be  provided  in  a  secure,  Web-based, 
global  environment — one  that  adheres  to  sound  data  standards  to  reduce  redundancy  and 
to  leverage  transparency  and  interoperability  (DoN,  2005,  May  3). 

Going  forward,  DoN  information  systems — including  those  related  to  Human 
Resource  Management  (HRM) — are  required  to  be  fully  integrated  solutions  within  an 
open,  Services-oriented  Architecture  (DoN  FMOC,  2006).  In  addition  to  the 
aforementioned  requirements,  there  has  been  a  proposal  by  the  Manpower,  Personnel, 
Training  and  Education  (MPTE)  Chief  Information  Officer  (CIO)  code  N16,  to  combine 
the  data  into  one  cleansed,  metadata  tagged,  indexable  and  searchable  Enterprise  Data 
Environment  (EDE)  (Navy  MPTE,  2008).  This  environment  will  resolve  redundant 
storage  issues,  as  well  as  eliminate  outdated,  end-of-lifecycle  equipment  and  legacy 
infrastructure.  Figure  13  depicts  the  vision  of  the  Navy  Program  Executive  Office  (PEO) 
for  Enterprise  Information  Systems  (EIS)  of  how  data  from  the  current  MPTE  system 
will  be  mapped  to  the  proposed  future  state  of  DoN  HRM  information  systems. 
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Figure  13.  Future  MPTE  Information  Technology  System  Structure 

(From  Murphy,  2007,  slide  10) 
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The  vision  painted  in  Figure  13  fits  into  the  overall  Chief  of  Navy  Personnel 
(CNP)  vision  of  the  future  enterprise,  which  is  shown  in  Figure  14.  This  figure  illustrates 
the  Data  Management  and  Integration  (DMI)  matrix  model.  The  DMI  approach  provides 
necessary  control,  information  exchange,  and  efficiency  of  data  operations.  “To  achieve 
this,  data  governance,  data  architecture,  and  data  sharing — the  ‘Three  Pillars’  of  data 
management — provide  the  framework  for  the  operational  focus  of  the  DMI  Roadmap” 
(Pavelec,  2008,  p.  2).  Within  the  matrix,  the  MPTE  databases  are  represented  in  the 
orange  cubes  as  the  basis  for  the  Enterprise  Data  Environment  (EDE).  It  is  to  this  new 
model  that  the  RFIS  will  be  required  to  migrate. 


Transforming  the  heart-lung  business  and  technology  model  to  a  disciplined, 
integrated  acquisition  and  product  development  model 
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Figure  14.  Chief  of  Navy  Personnel  (CNP)  IT  vision 
(From  Murphy,  2007,  slide  10) 
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1.  Enterprise  Data  Environment 


In  2008,  the  MPTE  CIO  directed  that  an  Enterprise  Data  Environment  (EDE) 
proof-of-concept  pilot  project  be  executed  by  the  Space  and  Naval  Warfare  Systems 
Command,  New  Orleans  (SSC  NOLA).  In  the  Statement  of  Objectives,  the  PM  for  the 
project  described  the  SSC  NOLA’s  objective  this  way:  “an  agile  and  trusted,  fully 
integrated  data  enviromnent  that  is  built  on  a  Services  Oriented  Architecture  (SOA)  to 
provide  the  foundation  for  net-centric  data  services  to  the  enterprise”  (Navy  MPTE,  2008, 
p.  1).  Six  specific  objectives  from  the  Statement  of  Objective  relating  to  the  EDE  follow: 

1 .  Develop  an  N 1  (Navy  Personnel)  Enterprise  Information  Management  (EIM) 
framework  detailing  management  practices,  governance,  accountability,  and 
metrics  to  drive  data-quality  improvement; 

2.  Facilitate  the  validation  of  the  N 1  EIM  framework  to  determine  if  it  is  executable 
and  repeatable; 

3.  Prove  the  adaptability  and  scalability  of  the  SSC  NOLA  EDE; 

4.  Meet  the  OPNAV  N6  (Deputy  Chief  of  Navy  Operations  (CNO)  Communication 
Networks)  goals  and  objectives  described  below; 

5.  Integrate  N1  data  from  legacy  systems  to  a  modern  SOA-capable  data  store — 
providing  a  single  source  of  clean,  integrated,  active  and  reserve  manpower  and 
personnel  data; 

6.  Determine  whether  the  EDE  is  a  viable  source  for  clean,  authoritative  data  to 
support  DIMHRS  data  migration.  (2008,  p.  1) 

As  of  June  of  2008,  SSC  NOLA  staff  assigned  to  the  pilot  project  had 
successfully  migrated  MPTE  data  from  the  Navy  Enlisted  System  (NES)  and  the  Officer 
Personnel  Information  System  (OPINS)  to  the  EDE.  Some  benefits  from  the  project  are 
listed  below.  Their  corresponding  objective  numbers  from  the  Statement  of  Objectives 
are  captured  in  parentheses: 

•  Successfully  developed  and  implemented  a  data-integration  strategy  (2,  3, 
4,5), 

•  Defined  data  logic  and  business  processes  (1,  2,  3,  4),  and 

•  Created  authoritative  documentation  (1). 
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Successful  completion  of  the  EDE  pilot  project  marked  the  first  time  that  the 
Navy  data  environment  demonstrated  the  use  of  “modern  data  engineering  methods  (e.g., 
SOA,  metadata)  to  implement  a  system  that  satisfies  the  major  challenges”  of  data 
management  and  migration  (SSC  New  Orleans,  2008,  slide  18).  In  addition,  the  pilot 
data  that  was  migrated  was  “clean,  useable,  authoritative,  and  up  to  date”  (slide  18). 
These  results  are  in  accord  with  the  Navy’s  plan  regarding  its  data  management  and  the 
technologies  used;  these  results  also  met  with  the  objectives  that  the  MPTE  CIO  defined 
for  the  EDE  pilot  project. 

Subsequent  to  the  EDE  pilot  project  and  in  support  of  the  CNP  Vision,  SSC 
NOLA  has  been  directed  by  the  MPTE  CIO  to  support  the  “migration  of  the  Navy's 
legacy  manpower  and  personnel  information  systems  data  and  functionality  into  an  EDE 
that  offers  secure,  accurate,  authoritative  information”  (SSC  NOLA,  2009,  p.  1). 
Additionally,  SSC  NOLA  has  proposed  that  the  EDE  solution  be  used  as  a  way  to 
position  MPTE  information  systems  for  eventual  migration  to  the  DIMHRS,  and  that 
Navy-unique  data  (non-DIMHRS)  be  transferred  as  well.  Further,  SSC  NOLA  has 
proposed  that  the  EDE  be  used  as  “the  foundation  for  N 1  IT  legacy  modernization — even 
if  DIMHRS  fails”  (SSC  NOLA,  2008,  slide  16).  Figures  15  and  16  depict  the  DIMHRS 
alternative  migration  strategies  designed  by  SSC  NOLA.  Figure  15  (direct  solution) 
shows  the  direct  transition  of  N1  (MPTE)  legacy  systems  to  the  DIMHRS,  while  Figure 
16  (EDE  solution)  depicts  a  transition  to  an  EDE  prior  to  migration  to  the  DIMHRS.  The 
direct  solution  would  require  “investment  to  develop  and  implement  a  data  integration 
strategy,  with  solution  architecture,  to  deliver  capability,”  and  both  “Technical  and 
functional  governance  risks  apply”  (SSC  NOLA,  2008,  slide  20).  On  the  other  hand,  the 
EDE  solution  would  benefit  from  the  work  completed  and  lessons  learned  on  the  EDE 
pilot  project;  in  addition,  the  “Remaining  N1  portfolio  leverages  component  SOA 
architecture”  (2008,  slide  20).  In  this  scenario,  the  technical  risks  of  migrating  directly  to 
the  DIMHRS  would  (according  to  SSC  NOLA)  be  “dramatically  mitigated”  (2008), 
while  functional  governance  risks  would  still  apply. 
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Figure  15.  MPTE  Transition  Options — Move  Directly  to  the  DIMHRS 

(After  SSC  NOLA,  2008,  slide  20) 


Figure  16.  MPTE  Transition  Options — Move  an  EDE  First 
(After  SSC  NOLA,  2008,  slide  20) 

The  resulting  MPTE  system  diagram  seen  in  Figure  16  would  be  significantly 
cleaner  than  the  current  state  shown  in  Chapter  I,  Figure  1. 

Finally,  according  to  SSC  NOLA,  the  EDE  offers  cost  reductions  of  30-50% 
below  current  systems  costs  in  development  and  Operating  and  Maintenance  (O&M)  and 
also  provides  a  more  flexible  system  for  less  expensive  and  more  efficient  changes  in  the 
future.  Currently,  it  appears  that  the  SSC  NOLA  EDE  is  the  most  likely  solution  for  REIS 
migration.  The  next  section  focuses  on  the  desired  state  of  the  RHS. 
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Figure  17.  Desired/Future  MPTE  System  Overview 
(From  Murphy,  2007,  slide  8) 


C.  RESERVE  HEADQUARTERS  SUPPORT  (RHS)— DESIRED  STATE 

In  this  section,  we  turn  our  attention  to  the  focus  system  of  this  paper:  the  Reserve 

Headquarters  Support  (RHS).  Here,  the  desired  state  of  the  RHS  is  defined  from  the 

perspective  of  the  system  owners,  the  Commander  Navy  Reserve  Force  Command 

(CNRFC)  Nl-Chief  of  Personnel,  and  the  N6-Chief  Information  Officer  (CIO); 

however,  we  still  recognize  the  desired  IT  system  state  of  those  higher  Echelons 

discussed  previously.  CNRFC  is  fully  aware  of  the  shortcomings  of  the  RHS  as  it  exists 

today  and  is  committed  to  creating  a  system  that  is  modern,  compliant  and  flexible.  To 

this  end,  CNRFC  (business  owner  of  the  RHS)  requested  that  SSC  NOLA  (technical 

owner  of  the  RHS)  conduct  a  RHS  technical  re-engineering  study  in  February  of  2008. 
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The  primary  objective  of  this  study  was  to  assess  the  cost  to  “Migrate  the  current  RHS 
Application  to  a  more  modem  technology  and  architecture.  This  includes  hardware  and 
software  upgrades  that  are  Navy  and  DoD  Information  Assurance  Compliant.  The  cost 
proposal  includes  all  of  the  work  necessary  to  accomplish  this  objective”  (Robertson, 

2008,  p.  11). 

The  study  specified  the  following  services,  deliverables,  and  assumptions: 
Services:  (to  be  provided  by  SSC  NOLA) 

•  Migrate  the  RHS  application  to  a  multi-tiered  Java/Web-based 
architecture, 

•  Upgrade  current  database  software, 

•  Re-write  the  current  application,  and 

Train  personnel  on  the  new  system. 

Deliverables: 

•  Completed  set  (baseline)  of  functional  requirements  implemented  in  the 
RHS  application, 

•  An  upgraded  and  re-designed  set  of  software  components, 

•  Upgraded  database, 

•  Systems  Security  Authorization  Agreement  (SSAA),  and 

•  Modernized  development,  test,  and  production  environments — including 

hardware,  software,  and  infrastructure. 

Assumptions: 

•  No  additional  hardware,  software,  or  licensing  will  need  to  be  purchased 
beyond  that  already  identified  in  this  IPE. 

•  The  new  application  will  only  contain  existing  system  functionality. 

•  CNRFC  will  designate  and  assure  availability  of  responsible  and 
knowledgeable  personnel,  as  scheduled  in  the  project  plan,  to: 

•  Review  and  approve  system  requirements, 

•  Perform  beta  testing  for  each  build, 

•  Perform  user  acceptance  testing,  and 

•  Support  the  production  environment  transition  activities. 
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•  Implementation  Training  will  be  conducted  by  SSC  NOLA  personnel  at 
SSC  NOLA.  (Robertson,  2008,  p.  12) 

Together,  these  services,  deliverables  and  assumptions  combine  to  create  a  list  of 
requirements  that  will  help  CNRFC  reach  its  desired  state  pertinent  to  the  RHS.  They 
define  “what”  the  future  system  must  do  without  dictating  “how”  to  do  it.  This 
distinction  is  important,  as  it  leaves  the  architectural  possibilities  wide  open  in  regards  to 
the  system’s  eventual  re-engineering.  Also  important  to  note  is  that  only  existing 
functionality  is  to  be  migrated  to  the  new  solution;  such  specificity  may  help  to  control 
the  possible  problems  associated  with  migration.  CNRFC  desires  that  the  technology 
underlying  the  RHS  be  updated  so  that  it  will  work  more  efficiently,  be  compliant  with 
DoD  instructions,  be  interoperable  with  other  DoD  systems,  and  be  readily  upgradeable 
to  meet  future  requirements. 

1.  How  to  Get  to  the  Desired  State 

Figure  17  shows  the  MPTE  CIO’s  perspective  in  regards  to  how  the  MPTE 
organization  will  look  from  a  data  management  standpoint.  Of  particular  interest  in  this 
section  is  the  role  that  the  RHS  plays  in  this  environment.  It  will  be  expected  to  be 
capable  of  fitting  into  the  Shared  Services  portion  of  the  Navy  enterprise  architecture  by 
being  accessible  to  other  applications  within  the  enterprise.  As  such,  it  will  need  to  be 
compliant  with  the  strategy,  policies,  data  management  standards,  reconciliation,  and 
quality  assurance  aspects  of  the  Enterprise  Information  Management  (EIM)  strategy. 
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Figure  18.  To-Be  MPTE  Data  Management  Environment  (Pavelec,  2008,  p.  4) 


2.  Architecture  Possibilities 

To  reach  this  state,  the  Navy  has  decided  to  implement  a  Service-oriented 
Architecture  (SOA),  which  is  an  architecture  that  is  based  upon  a  meshing  of  software 
services  provided  by  different  system  owners.  This  type  of  architecture  does  not  rely  on 
hard-coded  calls  to  other  systems;  instead,  the  services  offered  by  an  organization  are 
published,  and  organizations  seeking  the  kind  of  service  offered  can  pull  the  information 
from  the  services  it  desires.  The  following  description  of  an  SOA  provided  by  the  Naval 
Network  Warfare  Command  is  instructive. 

FORCEnet  requires  a  service-oriented  architecture  based  on  several 
principles.  First,  any  node  can  establish  a  presence  on  the  network  through 
which  it  can  post  the  nature  and  location  of  its  services  and  information. 
Second,  others  can  easily  find  that  node  through  accessible  addressing. 

Third,  others  can  then  access  the  information  and  services  they  require, 
subject  to  necessary  restrictions.  Nodes  will  generally  gain  access  to 
information  and  services  by  subscribing  to  them.  In  this  way,  decision 
makers  choose,  or  “pull,”  the  information  they  need  for  their  decision¬ 
making.  This  general  “pull”  approach  should  be  balanced  by  intelligent 
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“push,”  whereby  decision  makers  receive  exceptional  information  they 
have  not  requested  but  which  is  deemed  by  some  authority  to  be  important 
to  them.  (2009a,  p.  1 1) 

From  the  RHS  re-engineering  project  discussed  previously,  CNRFC  proposes  to 
meet  this  state  by  making  the  RHS  a  Web-based  application.  By  doing  so,  the  RHS  will 
be  accessible  to  other  enterprise  applications  that  are  also  Web-based — thereby  making 
itself  accessible  within  an  enterprise  SOA.  Figure  18  depicts  the  organization  of  the 
MPTE  EIM  concept,  wherein  the  RHS  would  reside  in  Echelon  III  as  part  of  the  Pay  & 
Personnel  service  governed  by  Echelons  I  and  II. 


Figure  19.  Enterprise  Information  Management  (EIM)  Organization  for  MPTE 

(From  Pavelec,  n.d.,  slide  8) 
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In  conjunction  with  the  above-stated  services,  deliverables,  and  assumptions 
defined  by  CNRFC,  the  following  guidance  from  the  MPTE  CIO  further  defines  the 
requirements  for  which  the  RHS  will  be  responsible: 

•  Integration  with  cross-functional  domain  areas, 

•  Data,  metadata  management  and  semantic  reconciliation, 

•  Data  integration  across  the  IT  portfolio,  including: 

•  Systems/ Apps  (SOA) 

•  IA 

•  Provision  of  unify-able  and  converge-able  content,  and 

•  Ability  to  meet  with  governance: 

•  Standards 

•  Cost  control 

•  Enterprise  and  strategic  alignment. 

Combining  all  of  the  elements  of  the  re-engineering  project  and  the  above 
guidance  from  the  MPTE  CIO,  a  workable  list  of  requirements  can  be  pieced  together 
that  defines  the  desired  state  of  the  RHS.  This  requirements  list  will  be  in  accordance 
with  the  direction  set  forth  by  the  DoD  and  further  refined  by  the  DoN,  while  making 
sure  that  the  RHS  becomes  a  more  useable  application  both  now  and  into  the  future. 

3.  Acquisition/Development  Method 

Table  3,  taken  from  the  PEO  EIS  (Murphy,  2007,  slide  30),  shows  the  current 
funding  level  (baseline)  and  the  proposed  funding  level  of  the  RHS.  Currently,  only  the 
system’s  Operation  Maintenance  Navy  (OMN)  is  funded.  Clearly,  CNRFC  cannot 
provide  the  desired  level  of  service  with  the  current  level  of  funding.  Even  the  proposed 
funding  level — which  shows  OMN  continuation,  along  with  proposed  Research 
Development  Training  and  Education  (RDT&E)  funding — by  itself  is  inadequate  to  meet 
the  envisioned  future  state  of  the  RHS. 
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Table  3.  Reserve  Headquarters  Support  (RHS)  Funding  and  Proposed  Changes 

(^figures  in  thousands) 

(From  Murphy,  2007,  slide  30) 


APPN/LI/P^  FY08 

FY09  FY1 0  FY1 1 

FY1 2 

FY1 3 

FY1 4 

FY15 

FYDP 

PR-09  Baseline 

OMN 

812 

1 000  0  0 

0 

0 

0 

0 

1812 

RDTE 

0 

o 

O 

O 

0 

0 

0 

0 

0 

OPN 

POM -10  Proposed 

OMN  874 

998  1  033  1  069 

1106 

1145 

611 

632 

7468 

RDTE 

0 

0  1 000  1 250 

1250 

1000 

0 

0 

4500 

OPN 

Delta 

OMN 

(62) 

2  (1033)  (1069) 

(1106) 

(1145) 

(611) 

(632) 

(5656) 

RDTE 

0 

0  (1000)  (1250) 

(1250) 

(1000) 

0 

0 

(4500) 

OPN 

Funding-level  estimates  taken  from  the  RHS  Cost  Migration  Model  (Figure  19) 
put  the  cost  of  the  effort  over  $13  million  in  RDT&E  funding  alone,  versus  the  $4.5 
million  proposed  in  the  PEO  EIS  plan. 


14  Estimated  Cost  The  estimated  cost  for  the  RHS  Technical  Re-enqineering 

Application  Software  Development 

$12,922,547 

Database  &  App/Web  Server  Setup  &  Config 

$  30,000 

Implementation  and  Training 

$  30.000 

Software  and  Licensing 

$  50.000 

Security 

$  54,000 

TOTAL  RDT&E 

r$  13,086,547 

Figure  20.  SSC  NOLA  Estimate  to  Re-engineer  RHS  (From  Robertson,  2008,  p.  12) 


To  meet  the  proposed  desired  state  of  the  RHS,  decision-makers  must  draft  a 
realistic  funding  estimate.  The  estimates  of  both  the  PEO  EIS  and  SSC  NOLA  need  to  be 
considered.  Thus,  possible  research  could  be  conducted  reconciling  these  estimates  and 
using  them  as  baselines  from  which  to  draft  an  estimate.  The  estimate  must  recognize  the 
requirements  for  the  functionality  of  the  system  (described  herein),  along  with  the  timing 
of  the  execution  of  the  proposed  funding.  Additionally,  funding  that  has  been 
appropriated  for  the  migration  of  Navy  data  to  the  DIMHRS  should  be  studied  to 
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determine  if  any  of  those  funds  would  be  more  appropriately  directed  towards  the  efforts 
of  re-engineering  the  RHS.  By  re-programming  the  RHS  DIMHRS  funding  to  RDT&E 
and  Operation  Procurement  Navy  (OPN)  for  the  RHS,  CNRFC  will  assume  control  over 
re-engineering  efforts.  It  would  then  be  able  to  move  the  RHS  to  an  EDE  regardless  of 
the  future  platform  (DIMHRS  included).  This  solution  would  enable  the  RHS  to  attain 
the  desired  state  and  make  it  possible  for  the  system  to  be  integrated  more  readily  at  a 
later  date  by  the  DIMHRS,  or  by  any  other  SOA-based  product. 

As  discussed  earlier,  SSC  NOLA  has  demonstrated  the  ability  to  transfer 
application  data  to  an  EDE.  The  next  step  is  to  ensure  the  appropriate  stakeholders:  1) 
create  a  transfer  plan  that  includes  a  prioritized  list  of  systems  to  migrate  to  the  EDE,  and 
then  2)  execute  the  plan.  If  this  happens,  programs  will  be  funded  for  migration  based 
upon  their  priority  level.  This  process  will  allow  for  incremental  gains  towards  an  overall 
enterprise  solution. 

In  this  chapter,  the  desired  state  of  information  systems  has  been  described  from 
the  DoD  organizational  level  down  to  the  RHS  system  level.  Challenges  associated  with 
creating  the  desired  state  for  the  RHS  have  been  described  in  terms  of  technical, 
personnel,  and  acquisition  hurdles.  In  the  next  chapter,  solutions  will  be  proposed  to 
overcome  them. 
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IV.  PROPOSED  WAY  FORWARD  AND  ASSOCIATED  COSTS 


To  this  point,  this  research  has  focused  on  describing  known  or  verifiable  facts 
about  the  information  technology  systems  related  to  Human  Resource  Management 
(HRM)  within  the  Department  of  Defense  (DoD).  The  current  state  and  desired  states  of 
the  pertinent  IT  systems  and  their  associated  business  processes  have  been  described.  In 
this  chapter,  focus  will  shift  to  examining  philosophies,  tools,  and  techniques  that  can  be 
used  to  transition  current  systems  to  desired  end-states.  To  begin,  the  DoD  will  be 
examined,  and  essential  elements  that  need  to  be  in  place  at  this  level  for  downstream 
systems  to  be  successfully  implemented  will  be  discussed.  Focus  will  then  shift  to 
examining  how  the  Department  of  the  Navy  (DoN)  can  further  enable  successful 
transfonnation  of  its  IT  assets  in  support  of  the  DoD.  Next,  the  Reserve  Headquarters 
Support  system  (RHS)  will  be  studied  to  determine  the  steps  that  will  need  to  be  taken  to 
ensure  its  future  success  within  the  business  application  portfolio  of  the  Navy  and  DoD. 
Finally,  costs  associated  with  three  alternative  states  of  the  RHS  will  be  discussed. 

A.  DEPARTMENT  OF  DEFENSE 

Chapter  II  described  IT  systems  and  business  processes  within  the  DoD  as  being 
highly  partitioned  and  poorly  suited  to  support  cross-organizational  business  practices 
and  processes.  In  particular,  efficient  and  effective  utilization  of  human  assets  has 
proven  to  be  difficult  in  a  joint  organization  environment.  Chapter  III  then  described  the 
desired  state  of  business  process  IT  applications  that  would  rectify  many  of  the  current 
shortcomings.  In  fact,  much  progress  has  been  made  to  this  end.  A  great  deal  of 
guidance  has  been  forwarded  to  the  DoD  from  Congress  describing  what  DoD-related  IT 
systems  must  be  able  to  do  and,  in  some  cases,  the  necessary  steps  to  do  it.  Although  this 
type  of  guidance  has  been  in  place  long  before  2005,  this  year  is  important  because  it 
marked  the  creation  of  the  Business  Transformation  Agency  (BTA).  Through  the  BTA, 
the  guidelines  and  rules  provided  by  Congress  have  been  codified  and  institutionalized  in 
the  form  of  the  Business  Enterprise  Architecture  (BEA),  the  Enterprise  Transition  Plan 
(. ETP ),  and  the  Business  Investment  Review  Boards  (IRBS).  These  tools  provide  a 
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starting  point  and  reference  material  for  all  entities  that  operate  within  the  DoD  that  are 
engaged  in  transition- type  projects.  In  the  following  paragraphs,  some  ideas  on  how  to 
increase  the  likelihood  of  successful  implementation  of  the  BTA’s  vision  are  discussed. 

1.  Building  a  Foundation  for  Execution 

In  their  research,  Ross,  Weill,  and  Robertson  studied  hundreds  of  companies  that 
have  experience  in  implementing  enterprise  architectures.  They  found  that  the  companies 
that  were  the  most  successful  in  this  endeavor  followed  some  common  practices.  These 
findings  form  the  basis  for  their  assertion  that  to  successfully  execute  business  strategies 
through  IT  solutions,  companies  must  master  the  three  following  disciplines. 

1.  They  must  establish  and  use  an  operating  model.  This  is  highly 
important  to  this  study,  as  “it  forces  a  common  understanding  of  data  across  diverse 
business  units”  (Ross,  Weill  &  Robertson,  2006,  p.  8).  This  commonality  is  ultimately 
what  the  RHS,  the  Navy,  and  the  DoD  would  like  to  achieve.  The  operating  model 
describes  the  amount  of  process  integration  necessary  within  an  organization  to 
successfully  deliver  services  to  the  customer.  (More  on  this  is  described  in  the  following 
section,  choosing  an  operating  model.) 

2.  Implement  and  use  enterprise  architecture.  Ross  et  al.  (2006) 
explain  that,  “The  enterprise  architecture  is  the  organizing  logic  for  business  processes 
and  IT  infrastructure,  reflecting  the  integration  and  standardization  requirements  of  the 
company’s  operating  model”  (p.  9).  Further,  an  enterprise  architecture  enables  individual 
projects  to  “build  capabilities — not  just  fill  immediate  needs”  (p.  9).  This  step  ties  the 
operating  model  to  the  IT  systems  of  the  organization. 

3.  Develop  and  use  an  IT  engagement  model.  An  engagement  model 
presents  the  rules  established  by  the  organization’s  headquarters  that  must  be  followed  by 
subordinate  business  units.  This  is  where  an  organization’s  internal  and  external 
regulations,  technical  standards,  development  and  implementation  standards  are 
addressed. 
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Why  is  building  a  foundation  for  execution  important  to  the  DoD?  First, 
Ross  et  al.  (2006)  explain  that  companies  that  have  a  solid  foundation  have  proven  to  be 
more  efficient  and  flexible  to  shifting  customer  demands — which  are  common  within  the 
DoD.  This  is  followed  by  the  assessment  that  as  a  company  increases  in  size  and  its  IT 
systems  become  more  complex,  those  systems  run  the  risk  of  becoming  inflexible — thus 
creating  a  situation  in  which  changes  to  the  system  “becomes  a  risky,  expensive 
adventure”  (p.  11).  Examples  of  this  danger  are  numerous  in  the  DoD;  the  RHS  is  one 
such  example.  A  strong  foundation  for  execution  helps  to  alleviate  these  negative  effects 
by  providing  the  organization  with  a  scalable  foundation.  Additionally,  a  solid 
foundation  leads  to  more  readily  shareable  data,  giving  the  organization  the  flexibility 
needed  to  adjust  to  new  requirements  and  regulations.  This  is  one  of  the  primary  goals  of 
the  BTA,  as  it  works  to  implement  enterprise  architecture  at  the  DoD  level  and  to 
incorporate  subordinate  organizations’  business  IT  functions.  Finally,  as  the  foundation 
matures,  business  processes  become  more  efficient,  and  IT  costs  are  lowered. 

2.  Choosing  an  Operating  Model  and  Implementing  the  IT  Engagement 
Model 

In  their  book,  Enterprise  Architecture  as  Strategy,  Ross  et  al.  (2006)  present  four 
possible  operating  models  from  which  organizations  could  choose.  This  decision  should 
be  based  upon  the  models’  fit  to  their  organization’s  business  model.  The  models  contain 
four  quadrants  based  upon  two  axes:  vertical  axis  determines  business  process  integration 
and  horizontal  axis  corresponds  to  business  process  standardization.  Ross  et  al.  describe 
integration  as  linking  “the  organizational  units  through  shared  data”  (2006,  p.  27). 
Likewise,  they  identify  standardization  as  “defining  exactly  how  a  process  will  be 
executed  regardless  of  who  is  performing  the  process”  (p.  27).  The  four  quadrants  are 
based  upon  where  in  the  spectrum  an  organization  lies  regarding  these  two  metrics — 
either  low  or  high.  Table  4  shows  the  four  types  of  operating  models  and  their  associated 
characteristics. 
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Table  4.  Four  Operating  Models  (After  Ross,  et  al,  2006,  p.  29) 


I 

n 

t 

e 

g 

r 

a 

t 

i 

o 

n 


Coordination 

Unification 

-  Shared  customers 

-  Customers  and  suppliers 

-  Impacts  other  business 

local  or  global 

unit  transactions 

-  Globally  integrated 

-  Operationally  unique 

business  processes 

business  units 

-  Business  units  w/  similar 

-  Autonomous  business 

or  overlapping  operations 

management 

-  Centralized  management 

-  Bus.  unit  control  over 

applies  functional/process 

process  design 

unit  matrices 

-  Shared  customer  data 

-  High-level  process  owners 

-  Consensus  processes  for  IT 

design  standard  processes 

infrastructure  services;  IT 

-  Centrally  mandated 

app.  decisions  made  in  Bus. 

databases 

units 

-  IT  decisions  made 
centrally 

Diversification 

Redication 

-  Few  shared  customers 

-  Few  shared  customers 

Independent  transactions 

-  Transactions  aggregated 

Operationally  unique 

at  high  level 

business  units 

-  Operationally  similar 

-  Autonomous  Bus .  Mgmt . 

business  units 

-  Business  unit  control 

-  Business  unit  leaders  w/ 

over  processes 

limited  process  control 

-  Few  data  standards 

-  Central  control  over 

-  Most  IT  decisions  made 

business  process  design 

w/in  business  units 

-  Standard  data  definitions 
with  locally  owned  data  and 
some  aggregation 

-  Centrally  mandated  IT 
services 

Low 

Standardization 

High 

The  BTA  has  somewhat  defined  the  type  of  operating  model  for  the  human 
resource  management  (HRM)  business  function  of  the  DoD  as  Unification.  This  is  based 
upon  the  fact  that  the  DIMHRS  is  the  proposed  sole  solution  for  the  human  resource 
function  of  the  DoD — incorporating  a  high  degree  of  both  cross-organizational  business 
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process  standardization  and  process  integration.  Whether  this  is  the  appropriate  choice  or 
not  is  debatable  and  will  be  revisited  later  in  the  paper.  For  now,  it  will  be  assumed  that 
the  unification  operating  model  is  a  better  option  than  the  current  diversification 
operating  model  that  is  typified  by  both  low  process  standardization  and  integration,  and 
is  the  proper  choice  to  enable  the  transition  from  the  current  state  of  DoD  IT-related 
business  systems  to  the  desired  end-state.  The  DoD  has  given  considerable  focus  to  the 
development  of  an  IT  Engagement  Model  which  is  a  necessary  component  to  creating  a 
foundation  for  successful  execution.  As  discussed  in  the  opening  paragraph  of  this 
section,  the  BEA,  ETP,  and  the  IRBS  form  the  library  of  guidance  and  standards  under 
which  the  DoD  will  continue  its  IT  systems  transformation  efforts.  In  the  next  section, 
attention  is  turned  to  the  next  step  in  creating  a  foundation  for  execution:  implementing 
the  operating  model  through  enterprise  architecture. 


3.  Implementing  the  Enterprise  Architecture 


Step  two  of  building  a  foundation  for  execution  is  to  implement  the  enterprise 
architecture  based  upon  the  selected  operating  model,  as  the  process  is  different  for  all 
four  models.  As  the  DoD  has  adopted  the  unification  operating  model,  the  enterprise 
architecture  diagram  would  be  similar  to  that  depicted  in  Figure  2 1 . 


-  Required 

-  Optional 


a 

o 


Business 

process 

Data 

Technology 


Customer  types 


Figure  2 1 .  Unification  Model  EA  Diagram  (After  Ross  et  ah,  2006) 
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This  diagram  represents  the  structure  that  a  successful  implementation  of  the 
DoD’s  chosen  operating  model  could  take.  In  the  diagram,  there  are  relatively  few 
business  processes  shown,  reflecting  the  high  standardization  associated  with  the 
coordination  model.  For  example,  the  long  cylinder  (business  process)  at  the  bottom  of 
the  diagram  would  be  a  close  approximation  of  the  DIMHRS,  in  which  all  DoD 
personnel  and  pay  systems  would  be  standardized  and  integrated  with  organizational  data 
via  technology.  The  diagram  also  accounts  for  small  amounts  of  business-unit-specific 
functionality,  as  can  be  seen  by  the  non-enterprise-connected  technology  loop  highlighted 
in  red  in  the  diagram. 

4.  DoD  Stage  of  EA  Maturity 

As  an  organization  decides  to  adopt  an  enterprise  architecture,  Ross  et  al.  (2006) 
explain  that  it  will  progress  through  four  stages  of  maturity.  Although  it  is  not  necessary 
to  reach  level  four,  it  is  necessary  to  proceed  from  the  lower  levels  of  maturity  before 
attaining  higher  levels.  In  other  words,  stages  cannot  be  skipped.  Per  the  Ross  et  al.  text 
(2006),  the  four  stages  of  maturity  and  a  brief  description  of  the  associated  architectures 
follow. 

1.  Business  Silos :  Individual  business  and  functional  units’  needs  are  maximized. 

2.  Standardized  Technology.  Technology  standardization  increases  efficiencies,  and 
technology  management  is  generally  centralized. 

3.  Optimized  Core :  Provides  organization-wide  data  and  process  standardization. 

4.  Business  Modularity :  Business  process  components  are  available  for  reuse  and 
preserve  organizational  standards  while  enabling  local  differences. 

Currently,  as  described  in  the  previous  chapter,  the  DoD  via  the  BTA  is  seeking  to 
eventually  progress  through  all  of  the  levels  of  maturity.  It  is  clear  that  the  BTA  has 
correctly  assessed  the  DoD’s  current  level  of  maturity  as  falling  within  the  Business  Silo 
stage.  What  is  not  clear  is  whether  the  guidance  they  have  issued  leads  to  Stage  Two 
(Standardized  Technology)  or  Three  (Optimized  Core).  In  order  to  be  successful  in 
instituting  an  organization-wide  EA  to  reach  the  desired  state  of  IT  systems,  guidance 
from  the  BTA  must  clearly  be  directed  to  achieving  Stage  Two  maturities  before 
progressing  to  Stage  Three.  This  is  due  to  the  fact  that  each  stage  implements  building 
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blocks  that  will  be  built  upon  by  successor  stages.  The  progression  through  the  stages  is 
similar  to  the  construction  of  a  building  where  a  roof  cannot  be  applied  until  after  the 
walls  have  been  erected. 

5.  Application  within  the  Department  of  Defense 

By  incorporating  elements  discussed  (the  operating  model,  enterprise  architecture, 
and  IT  engagement  model),  the  DoD  will  not  only  transition  its  own  business  processes 
and  supporting  IT  systems,  it  will  also  provide  a  roadmap  for  its  subordinate 
organizations  to  follow.  In  addition,  it  will  provide  concrete  direction  for  subordinate 
organizations  on  how  to  modernize  all  levels  of  the  organization  by  codifying  the  steps  to 
do  so.  In  the  research  conducted  for  this  paper,  the  author  has  found  that  the  BTA  has 
made  progress  towards  mastering,  articulating,  and  implementing  these  disciplines.  In 
the  case  of  the  DIMHRS,  an  operating  model  has  been  chosen  (Unification);  copious  IT 
engagement  guidance  has  been  published,  and  progress  has  been  made  in  incorporating 
an  enterprise  architecture. 

B.  DEPARTMENT  OF  THE  NAVY 

In  this  chapter,  methodologies  to  transfonn  the  information  technology  (IT) 
systems  of  an  organization  have  been  described  drawing  heavily  from  the  Ross  et  al. 
(2006)  text.  The  steps  to  do  so  include  creating  a  foundation  for  execution,  selecting  an 
operating  model,  implementing  the  operating  model  via  enterprise  architecture  (EA),  and 
developing  an  IT  engagement  model.  These  steps  were  then  applied  to  the  DoD  and  to 
the  steps  the  BTA  has  taken  to  proceed  from  the  current  state  of  DoD  systems  to  the 
desired  state  of  IT  systems,  with  particular  emphasis  placed  on  the  human  resource 
application,  the  DIMHRS.  In  this  section,  attention  turns  to  the  Department  of  the  Navy 
(DoN)  and  the  steps  it  must  take  to  reach  its  desired  state  of  IT  systems.  Particular 
attention  will  be  placed  on  the  operating  model,  enterprise  architecture,  and  the  IT 
engagement  model.  Finally,  an  assessment  will  be  made  regarding  the  decisions  the  DoN 
must  make  to  be  successful  in  transforming  its  business  IT  processes  and  systems. 
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1. 


The  DoN  Operating  and  IT  Engagement  Models 


[I]f  all  forces  and  organizations  down  to  the  level  of  individual  entities  are 
interconnected  in  a  networked,  collaborative  command  and  control 
environment,  then  all  operations  and  activities  can  enjoy  the  benefits  of 
decentralization — initiative,  adaptability  and  increased  tempo — without 
sacrificing  the  coordination  or  unity  of  effort  typically  associated  with 
centralization.  (NETWARCOM,  2009a,  p.  1) 

The  above  passage  from  the  Naval  Network  Warfare  Command’s 
(NETWARCOM)  FORCEnet  concept  paper  seems  to  clearly  indicate  that  the  Navy  has 
chosen  to  implement  a  coordination  operating  model.  It  describes  an  environment  in 
which  IT  systems  are  highly  networked  and  integrated,  while  business  process  decision 
authority  is  maintained  at  the  sub-organizational  level.  To  help  illustrate,  the 
coordination  quadrant  (Table  5)  taken  from  Table  4  shows  operationally  unique  business 
units  controlling  process  design  while  leveraging  shared  customer  data. 


Table  5.  Coordination  Quadrant  from  the  Four  Operating  Models  Table — Table  4 

Coordination 

-  Shared  customers 

-  Impacts  other  business 
unit  transactions 

-  Operationally  unique 
business  units 

-  Autonomous  business 
management 

-  Bus.  unit  control  over 
process  design 

-  Shared  customer  data 

-  Consensus  processes  for  IT 
infrastructure  services;  IT 
app .  decisions  made  in  Bus. 
units 


It  is  interesting  to  note  that  this  choice  of  operating  model  differs  from  that  of  the 
DoD,  which  has  chosen  the  unification  model.  This  differing  choice  by  a  subordinate 
organization  should  not  cause  alann;  the  Ross  et  al.  (2006)  text  explains,  “Having 
different  operating  models  at  different  organizational  levels  allows”  an  organization,  “to 
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meet  the  multiple  objectives  of  large,  complex  companies  while  keeping  organizational 
design  reasonably  simple  at  the  individual  operating  company  level”  (2006,  p.  40).  The 
author  would  argue  that  it  makes  more  sense  for  the  DoN  to  apply  the  coordination  model 
than  the  unification  model  for  the  following  reasons: 

•  Easier  to  implement,  because  it  minimizes  changes  to  business 
applications. 

•  Allows  the  organization  to  focus  on  increasing  IT  system  integration. 

•  Enables  continued  use  of  legacy  business  applications  that  were 
customized  to  address  the  particular  needs  of  the  organization  and  its 
customers. 

These  are  just  a  few  of  many  potential  examples  of  why  selection  of  the 
coordination  operating  model  should  enable  the  DoN  to  complete  the  transition  from  its 
current  state  of  IT  systems  to  the  desired  state.  The  effects  of  this  choice  on  personnel 
systems  will  be  examined  from  a  Commander  Navy  Reserve  Forces  (CNRF)  perspective 
in  a  later  section. 


a.  IT  Engagement  Model 

For  the  Navy,  the  IT  engagement  model  has  been  given  careful 
consideration,  as  is  evident  from  the  following  passage  from  the  NETWARCOM:  “To 
support  standards  and  policy  compliancy,  organizations  developing  [Department  of 
Defense  Architecture  Framework]  DoDAF  architecture  products  will  receive  guidance 
from  the  FORCEnet  Integrated  Architecture  for  development  of  architectures  for  their 
[Program  of  Record]  POR  as  required  to  support  the  Joint  Capabilities  Integration  and 
Development  System  (JCIDS)  documents  or  for  other  purposes”  (NETWARCOM, 
2009b,  p.l).  Further,  Figure  22  illustrates  the  organizational  structure  that  will  be  utilized 
to  ensure  compliance  with  the  IT  engagement  model.  Combined,  this  corporate-level 
guidance,  along  with  supporting  guidance  from  the  DoD,  should  be  ample  to  guide  the 
DoN  through  the  transformation  of  its  business  IT  systems. 
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Figure  1  -  FORCEnet  Architecture  Governance  Organization 


Figure  22.  Navy  IT  Governance  (From  NETWARCOM,  2009b,  p.  2) 


2.  Implementing  the  Enterprise  Architecture 

As  discussed,  the  DoN  has  chosen  to  install  a  coordination  operating  model;  thus, 
it  must  build  an  enterprise  architecture  (EA)  specifically  tailored  to  support  this  choice. 
Figure  23  shows  the  basic  design  of  such  an  architecture.  Notice  that  the  arrows  at  the 
top  of  the  diagram  focus  on  shared  customers  and  data,  integrated  technology  and  linked 
processes.  This  differs  from  the  unification  model,  most  notably  in  the  area  of  customers 
(key  v.  shared)  and  process  standardization.  Again,  it  is  not  a  problem  to  utilize  different 
operating  models  at  different  levels  of  the  organizations,  and  integration  of  different 
operating  models  is  possible.  In  the  case  of  integrating  the  DoN  operating  model  into  the 
DoD  architecture,  the  DoN  architecture  would  be  treated  as  a  customer  within  the  DoD 
architecture.  This  would  still  allow  the  DoD  to  meet  its  goal  of  providing  department- 
level  data  to  the  entire  organization  while  allowing  the  DoN  to  build  an  EA  that  meets  its 
individual  business  needs. 
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Figure  23.  Coordination  EA  diagram  (After  Ross  et  al.,  2006) 


3.  DoN  Stage  of  EA  Maturity 

Similar  to  the  DoD,  the  DoN  is  currently  in  the  first  stage  of  the  maturity  model 
(business  silos)  and  is  working  towards  achieving  Stage  Two  (standardized  technology). 
In  the  author’s  view,  the  Navy  has  a  clear  understanding  of  where  it  stands  in  regards  to 
EA  maturity.  Evidence  to  support  this  position  includes  the  realization  that  it  has  no 
existing  EA  and  has  addressed  the  building  of  one  via  FORCEnet.  “The  FORCEnet 
Integrated  Architecture  is  the  first  naval  enterprise  level  architecture  that  will  guide 
multiple  programs  of  record  (POR)”  (NETWARCOM,  2009a,  p.  1).  Additionally,  the 
selection  of  the  coordination  operating  model  reflects  that  the  DoN  has  a  keen  sense  of 
self-awareness,  as  this  model  is  a  better  fit  for  organizations  working  to  reach  the 
standardized  technology  stage.  Indeed,  the  coordination  operating  model  by  definition 
assumes  that  an  organization  has  already  met  Stage  Two  maturity  because  the 
distinguishing  factor  of  Stage  Three  (optimized  core)  is  the  focus  placed  upon  process 
standardization.  This  is  not  to  say  that  organizations  in  Stage  Two  can  not  position 
themselves  for  progression  to  Stage  Three,  but  as  Ross  et  al.  (2006)  tell  us,  stages  in  the 
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EA  maturity  model  can’t  be  skipped.  “In  several  of  the  companies  we  spoke  to,  ERP 
implementations  that  tried  to  skip  stages  had  to  be  halted  or  scaled  back”  (Ross  et  ah, 
2006,  p.  82).  Next,  we  will  turn  our  attention  to  the  CNRF  and  the  Reserve  Headquarters 
Support  (RHS)  system,  and  the  steps  of  transitioning  it  to  its  desired  state. 

C.  RESERVE  HEADQUARTERS  SUPPORT  (RHS) 

In  this  section,  we  focus  on  the  Reserve  Headquarters  Support  (RHS)  system.  As 
the  RHS  is  a  subordinate  system,  and  the  CNRFC  is  a  subordinate  organization  to  the 
DoN  and  DoD,  the  latitude  in  choosing  the  elements  to  build  a  foundation  for  business 
execution  is  constrained  by  the  parent  organizations’  choices.  In  other  words,  the  RHS’s 
operating  model  will  either  be  the  coordination  model  (DoN  and  the  Enterprise  Data 
Environment  (EDE))  or  the  unification  model  (DoD  and  the  DIMHRS),  and  the  IT 
Engagement  model  used  will  be  the  FORCEnet  Integrated  Architecture  process  described 
in  the  previous  section.  The  implementation  of  the  operating  model  via  enterprise 
architecture  would  follow  the  diagram  associated  with  the  chosen  operating  model.  In 
the  following  evaluation  for  the  RHS  transformation,  three  alternatives  will  be  presented 
and  briefly  described.  These  alternatives  will  then  be  evaluated  using  the  Department  of 
the  Army  Economic  Analysis  Manual  as  a  guide  to  determine  the  best  choice  for  the  RHS 
transfonnation. 

1.  Economic  Analysis  of  the  RHS  Alternatives 

The  overall  evaluation  process  will  follow  the  model  depicted  in  Figure  24. 
According  to  the  United  States  Army  Cost  and  Economic  Analysis  Center  (USACEAC) 
EA  Manual, 

EAs  facilitate  the  decision  process  by  providing  a  strong  analytical 
framework  for  evaluating  alternatives,  identifying  costs  and  issues, 
highlighting  implications  of  individual  alternatives,  identifying  variables 
that  drive  results,  assessing  risks,  uncertainties,  and  sensitivities  of 
assumptions  and  costs,  and  suggesting  recommendations.  These  elements 
comprise  the  EA  process.  (USACEAC,  2001,  p.  5) 
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It  should  also  be  noted  that  per  the  EA  Manual  (p.  6  and  7):  “an  EA  will  not: 

•  Produce  results  that  are  more  valid  than  the  data  used  in  the 
analysis. 

•  Make  final  decisions. 

•  Be  applied  with  cookbook  precision;  instead  it  should  be  tailored  to 
fit  the  problem. 

•  Provide  relevant  solutions  to  irrelevant  questions  and  problems. 

•  Predict  political  and  non-economic  impacts. 

•  Substitute  for  sound  judgment,  management,  or  control.” 

In  this  paper,  a  basic  analysis  will  be  conducted  in  lieu  of  full  economic  analysis, 
which  would  be  beyond  the  scope  of  the  current  research.  The  intent  is  to  provide 
enough  analysis  of  the  alternatives  to  be  able  to  choose  the  best  from  among  them.  This 
research  could  form  the  basis  for  a  more  in-depth  study  at  a  later  date. 

In  the  following  analysis,  the  Reserve  Headquarters  Support  (RHS)  application 
and  potential  replacement  technologies  are  examined.  The  steps  will  be  numbered  from  1 
to  7,  and  each  step’s  function  (what  it  is  trying  to  elicit)  will  be  described  ( italicized ) 
based  upon  the  Department  of  the  Army — Economic  Analysis  Manual  (USACEAC, 
2001),  followed  by  the  actual  assessment  as  it  relates  to  this  study.  Some  of  the  steps  will 
require  a  discussion  and  justification  of  the  chosen  elements.  These  discussions  will 
follow  the  seven  steps’  EA  as  they  are  material  to,  but  not  an  actual  part  of  the  analysis. 
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Figure  24.  Economic  Analysis  Process  Model  (From  USACEAC,  2001,  p.  7) 


1.  Establish  objective.  This  is  a  clear  identification  of  the  mission-related 
objective(s)  and  should  be  consistent  with  the  existing  Mission  Need  Statement  (MNS), 
the  Operational  Requirements  Document  (ORD),  or  other  approved  requirements  source, 
as  applicable. 

The  objective  of  this  project  is  to  “Migrate  the  current  RHS  application  to  a  more 
modem  technology  and  architecture.  This  includes  hardware  and  software  upgrades  that 
are  Navy  and  DoD  Information  Assurance  compliant”  (Robertson,  2008,  p.  1 1). 

2.  Formulate  assumptions.  This  is  the  identification  of  assumptions  with 
underlying  rationale  explained  in  the  analysis. 

•  Project  Life.  The  project  to  implement  one  of  the  alternatives  to 
the  status  quo  should  not  take  so  long  that  it  creates  prohibitive 
monetary  costs  or  that  the  benefits  of  the  alternative  are  diminished 
to  a  level  below  that  of  the  current  system. 
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•  Economic  Life.  The  amount  of  time  that  this  project  (as  with  other 
large  technology  projects)  is  expected  to  be  beneficial  is  set  at  10 
years  after  being  put  into  production. 

•  Funding  will  be  provided  by  the  DoN  or  DoD. 

3.  Identify  constraints.  Identification  and  full  explanation  of project  constraints : 
assumed  or  imposed. 

—  The  solution  that  is  chosen  must  fit  within  the  FORCEnet  Integrated 
Architecture  framework. 

—  The  solution  needs  to  be  Navy  and  DoD  Information  Assurance  compliant. 

—  The  solution  must  be  funded. 

4.  Identify  alternatives.  This  step  includes  identification  of  the  status  quo  and  all 
feasible  alternatives.  If  a  candidate  alternative  is  eliminated,  specific  reasons  for 
dropping  that  alternative  must  be  documented  in  the  analysis. 

Alternative  1 — Do  Nothing  (maintain  status  quo) 

In  this  alternative,  the  RHS  application  would  remain  as  it  exists  in  production 
today,  with  all  of  its  features  and  inherent  flaws  as  described  in  Chapter  II — Current  State 
of  Information  Systems,  Section  C,  Reserve  Headquarters  System  (RHS). 

Alternative  2 — Build  to  the  DIMHRS  Standard 

This  alternative  would  involve  positioning  the  RHS  system  for  a  direct  transition 
to  the  DIMHRS.  This  option  would  be  contingent  upon  definitive  direction  from  the 
Business  Transfonnation  Agency  (BTA)  and  the  DoN  Chief  Information  Officer  (CIO) 
that  the  Navy’s  personnel  and  pay  IT  systems  were  slated  with  an  actual  timeframe  to  go 
live  with  the  DIMHRS. 

Alternative  3 — Build  to  an  EDE 

Building  to  an  Enterprise  Data  Environment  (EDE)  would  follow  the  solution 
proposed  by  SSC  NOLA  in  its  SSC  New  Orleans  Status  Brief  on  N1  Programs  and 
Budget  Issues  (SSC  NOLA,  2008).  This  solution  proposes  that  the  RHS  be  migrated  to 
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the  EDE  regardless  of  the  status  of  the  DIMHRS.  In  other  words,  this  solution  would  be 
able  to  stand  on  its  own,  or  it  could  be  migrated  to  DIMHRS  at  a  future  date. 

5.  Estimate  costs  and  benefits  for  each  alternative.  For  each  alternative,  an 
estimate  of  all  anticipated  costs,  both  direct  and  indirect,  over  the  economic  life  of  the 
project  is  derived.  The  methodologies  of  the  cost  estimates,  and  their  sources,  must  be 
clearly  identified  in  the  analysis. 

Cost  Estimates 

This  portion  of  the  analysis  adhered  to  the  following  guidance:  “Investment  costs 
are  normally  non-recurring  (occurring  one  time  or  on  an  intermittent  basis)  and  include  such 
items  as  research  and  development  (R&D),  equipment  purchases,  software  development, 
and  facilities  preparation.  Operating  and  Support  (O&S)  costs  are  normally  recurring 
(occur  on  a  continuing  annual  basis)  and  include  such  items  as  operating  personnel  and 
hardware  maintenance”  (USACEAC,  p.  25).  In  the  following,  R&D  equates  to  RDTE, 
and  O&S  equates  to  OMN. 


Table  6.  POM- 10  Proposed  Budget 
(Murphy,  2007,  slide  30) 


APPN/LI/P^  FY08 

FY09  FY1 0  FY1 1 

FY1 2 

FY1 3 

FY1 4 

FY1 5 

FYDP 

PR-09  Baseline 

OMN 

812 

1 000  0  0 

0 

0 

0 

0 

1812 

RDTE 

0 

0  0  0 

0 

0 

0 

0 

0 

OPN 

POM -10  Proposed 

OMN  874 

998  1  033  1  069 

1106 

1145 

611 

632 

7468 

RDTE 

0 

0  1 000  1 250 

1250 

1000 

0 

0 

4500 

OPN 

Delta 

OMN 

(62) 

2  (1033)  (1069) 

(1106) 

(1145) 

(611) 

(632) 

(5656) 

RDTE 

0 

0  (1000)  (1250) 

(1250) 

(1000) 

0 

0 

(4500) 

OPN 

Table  6  figures  will  be  used  in  the  cost-estimate  portion  of  this  EA.  Specifically, 

the  line  item  OMN  (sustainment)  funding  will  be  used  as  the  basis  to  estimate  ongoing 

funding  for  the  three  alternatives.  The  RDTE  line  will  be  used  for  Alternative  2  for 

DIMHRS  one-time  transition  costs,  while  funding  for  one-time  costs  (RDTE)  for 

Alternative  3  come  from  Figure  20.  FY10  through  FY15  will  be  used  as  a  baseline  to 

establish  future  year  estimates  for  FY16  through  FY19  OMN  funding.  Current  dollars 
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adjusted  for  inflation  3.5%  per  year  will  be  used  for  yearly  increases  in  OMN  funding. 
Table  7  shows  the  total  cost  by  alternative  to  run  each  system. 


Table  7.  Total  Projected  Costs  of  Alternatives 


FY’ 

Alternative  1 
(Status  Quo) 

OMN  RDTE 

Alternative  2 
(DIMHRS) 

OMN  RDTE 

Alternative  3  (EDE) 

OMN  RDTE 

10 

1.033 

1,033 

1.000 

1.033 

6.543 

11 

1.069 

1,069 

1,250 

1.069 

6.543 

12 

1,106 

1,106 

1.250 

611 

13 

1,145 

1,145 

1,000 

316 

14 

1,185 

611 

327 

15 

1227 

632 

339 

16 

1269 

654 

351 

17 

1,314 

677 

363 

18 

1,360 

701 

376 

19 

1.407 

725 

389 

12,115 

OMN  Tot. 

8.353 

4.500  OMN  Tot 

5,173 

13,086 

RDTE  Tot. 

4.500 

RDTE  Tot. 

13.086 

12,115 

Total  Cost 

12,853 

Total  Cost 

18,259 

Cost  totals  and  method  of  derivation  follow. 

Alternative  1  (Status  Quo)  -  $12.1  million 

For  Alternative  1,  only  sustainment  funding  (OMN)  was  estimated,  as  no 
development  investment  would  be  necessary.  FY10  through  FY15  dollars  come  from 
Table  6,  and  FY16  through  FY19  dollars  were  estimated  by  adjusting  for  inflation  and 
extrapolating  FY10  through  FY15  dollars. 

Alternative  2  (DIMHRS)  -  $12.9  million 

For  this  alternative,  Table  6  dollars  were  used  for  both  OMN  and  RDTE  funding. 
FY16  through  FY19  funding  was  calculated  using  the  same  method  as  Alternative  1. 

Alternative  3  (EDE)  -  $18.3  million 

This  alternative  required  more  estimation  than  the  first  two  alternatives,  due  to  the 
lack  of  proposed  budget  dollars  in  Table  6.  For  OMN  dollars,  FY10,  FY11,  and  FY12 
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were  taken  from  Table  6  as  follows:  FY10  and  FY1 1  used  same  dollars;  FY12  used  FY14 
dollars  because,  in  this  alternative,  the  EDE  project  would  go  live  during  FY12  (thus 
reducing  costs  as  reflected  in  FY14  dollars).  For  FY13  through  FY19,  OMN  costs  would 
be  further  reduced,  first  by  50%  in  FY13  (which  would  establish  a  new  reduced  OMN 
baseline)  and  then  by  applying  the  3.5%  inflation  rate  for  years  FY14  through  FY19. 
This  reduction  reflects  greater  expected  savings  over  Alternative  2  because  in  this 
alternative,  all  application  functionality  would  be  accounted  for;  yet,  in  the  DIMHRS 
solution,  not  all  functionality  would  be  subsumed. 

The  author  estimated  RDTE  funding  using  Robertson’s  (2008)  cost  estimate  to 
rewrite  the  RHS  application  for  migration  to  the  EDE  reflected  in  Table  20.  In  the 
estimate,  it  was  assumed  that  the  project  would  take  two  years  (26  months)  to  complete. 
Therefore,  the  estimate  to  complete  the  project  of  $13.1  million  was  divided  between 
FY10  and  FY11. 

Benefit  Analysis 

This  benefit  analysis  will  cover  both  quantifiable  and  non-quantifiable  benefits 
that  could  be  expected  to  accrue  to  each  of  the  focus  alternatives.  A  full  benefit  analysis 
is  complex  and  highly  detailed  and,  therefore,  beyond  the  scope  of  this  research. 
Therefore,  this  section  will  attempt  to  capture  the  most  applicable  benefits  based  upon  the 
available  data. 

Quantifiable  benefits 

Table  8  lists  the  types  of  benefits  that  are  quantifiable.  There  is  overlap  with  the 
items  in  this  table  and  those  listed  in  Table  9  (Non-quantifiable  benefits)  and  with  quality 
attributes  commonly  defined  by  IT  system  professionals.  For  this  portion  of  the  benefit 
analysis,  focus  is  on  the  cost  savings  of  the  systems. 
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Table  8.  Quantifiable  Benefits 


Quantifiab  le  Benefits 

Productivity  Improvem  ents 
Cost  Savings 

Improved  avail  ability'  measures  showing  when  a  system  will  be  delivered 
against  when  it  is  required 

improved  system  reliability 

Improved  maintainabi lity  supp o rtability  measures 

Improved  flexibility  and  adaptability  to  various  modes  of  operations 

improved  accuracy,  timeliness,  and  completeness  of  data  produced  by  a 
system  resulting  in  efficient  utilization  of  resources  through  more  effective 
decisions  made  upon  more  accurate  data 


Alternative  1  -  $0 

The  cost  savings  of  Alternative  1  are  the  costs  of  implementing  Alternative  2 
(DIMHRS)  $4.5  million  and  Alternative  3  (EDE)  $13.1  million.  However,  OMN  costs  of 
Alternative  1  are  higher  post-implementation  than  other  system  alternatives,  as  will  be 
shown  below. 

Alternative  2  -  ($700,000) 

Alternative  2  begins  accruing  OMN  cost  savings  in  the  year  following  projected 
implementation.  Such  savings  continue  through  the  remainder  of  the  10-year  period 
covered  in  this  analysis.  These  annual  savings  represent  a  48%  savings  versus 
Alternative  1,  and  account  for  a  total  of  $3.8  million  over  the  10-year  period.  Notice 
Alternative  2  is  only  $.7  million  more  costly  than  Alternative  1  ($4.5  million  savings  in 
Alternative  1  minus  the  $3.8  million  Alternative  2  savings).  The  $.7  million  dollars 
equals  the  difference  in  total  costs,  from  table  7,  of  Alternative  2  minus  Alternative  1 
($12,853  million  -  $12.1 15  million  =  $.738  million). 
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Alternative  3  -  ($6.1M) 

Similar  to  Alternative  2,  savings  for  this  alternative  come  from  savings  in  OMN 
funds.  However,  these  savings  begin  in  the  third  year  for  this  alternative  (FY12)  and 
total  $6.9  million  over  the  10-year  period.  However,  even  with  these  savings,  Alternative 
3  is  still  $6.1  million  more  costly  than  Alternative  1  over  the  10-year  period.  The  $6.1 
million  dollars  equals  the  difference  in  total  costs,  from  table  7,  of  Alternative  3  minus 
Alternative  1  ($18,259  million  -  $12.1 15  million  =  $6,144  million). 

N on-quantifiable  Benefits 

Table  9  drawn  from  the  EA  Manual  (USACEAC,  2008)  includes  a  detailed  list  of 
the  types  of  non-quantifiable  benefits  that  are  important  to  analyze  in  an  EA. 


Table  9.  Non-quantifiable  Benefits 

Non  Quantifiable  Benefits 


Acceptab  ilitv  —  does  die  alternative  contribute  to  the  operation  of  parallel  or  higher  level 
organizations?  Does  it  improve  the  quality  of  the  process? 

Accuracy  —  does  die  alternative  reduce  error  rates  or  improve  the  accuracy  of  information? 

Ad  a  p  t  ab  ilitv  —  is  the  system  project  adaptable  to  existing  DoD,  industry,  national,  or  international 
standards? 

Availability  —  when  can  the  system  project  be  delivered  orimplem  ented:  when  is  it  needed  to  meet 
proposed  output  schedules?  What  is  the  mean  time  between  failures? 

CompatibiKtv  —  hew  will  existing  operations,  facilities,  equipment,  data  requirements  be  affected? 
How  much  initial  training  will  be  required?  How-  will  work  methods  and  procedures  be  altered? 

F unctionalitv  —  how  well  does  die  system  perform:  how  quickly  can  it  process  data  or 
calculations,  or  other  functions? 

M ainta inability  —  is  the  system  difficult  to  repair?  Are  parts  readily  available?  How-  much  staff 
w  ill  be  required  to  maintain  the  software  hardware?  What  is  the  anticipated  down  time  for 
maintenance?  Is  the  maintenance  downtime  longer  for  any  alternative? 

Manageability  —  will  the  system  project  decrease  the  involvement  need  for  supervisors  or  quality 
inspections?  Will  a  different  type  of  personnel  than  currendy  assigned  be  required?  Are  trained 
personnel  available? 

Morale  -  will  the  system  proj  ect  contribute  to  a  positive  employee  attitude  towards  work? 
Production --will  the  number  of  products  produced  be  increased? 

Productivity  —  will  the  rate  of  production  increase?  Will  the  system  project  decrease  the  number 
of  staff  resources  previously  needed  to  produce  the  same  product,  or  will  the  system  project  allow- 
more  items  to  be  produced  with  existing  staff  resources? 

Qua  lit  v  —  will  a  better  product  be  produced?  Will  better  service  be  provided?  Will  quality  of 
products  be  more  consistent?  Is  customer  satisfaction  improved? 

Reliab ilitv  —  how  many- (how  often)  system  failureswill  occur  over  time? 

Security  —  will  more  or  less  precautions  be  needed? 

Service  life  —  how  long  will  the  equipment  be  able  to  support  the  operation?  Will  the  equipment  be 
obsolete  before  it  reaches  the  end  of  its  useful  life? 

UpgradeabiHtv  —  how  compatible  will  additional  equipment,  such  as  memory,  terminals, 
workstations,  or  other  eqmpm  ent,  be  with  existing  equipment  or  users  of  the  system? 

Versa tilitv  —  will  the  equipment  in  any  alternative  provide  additional  capacity"  or  capability  beyond 
that  required  for  the  system? 
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Combined  with  a  list  of  quality  attributes  drawn  from  Gorton  (2006),  the  most 
applicable  attributes  were  distilled  down  to  the  10  beneficial  attributes  used  in  this  study. 
Benefit  analysis  is  highly  subjective,  but,  the  author  has  built  this  list  based  upon 
applicability  to  the  current  issues  of  the  RHS  system  identified  in  Chapter  II  and  their 
ability  to  position  the  RHS  to  assume  the  desired  state  described  in  Chapter  III.  These 
metrics  are  highlighted  here  again  in  Table  10. 


Table  10.  Summary  of  Current  RHS  Issues  and  Desired  Future  Attributes. 


Current  State  Issues: 

Desired  State  Attributes: 

•  Lack  of  transparency 

•  Integrate  with  cross -functional  domain 

areas 

•  Excessive  interfaces 

•  Data,  metadata  management  and 
semantic  reconciliation 

•  Non-  compliance  with  DoD  and  DoN 

•  Data  integration  across  the  IT 

information  assurance  requirements 

portfolio,  including: 

•  Aging  hardwTare 

•  Systems  Apps  (SOA) 

•  Lack  of  experienced  technologists 

•  Informatio  Assurance  (LA) 

•  Data  definition  and  reliability  issues 

•  Provide  unify -able  and  converge-able 
content 

•  Poor  system  documentation 

•  Meet  with  governance: 

•  Difficult  to  support 

•  Standards 

•  Cost  control 

•  Enterprise  and  strategic  alignment 

After  the  benefit  attribute  list  was  complete,  each  attribute  was  weighted 
according  to  relative  importance  from  1  to  5,  with  5  being  the  most  important.  Then,  the 
alternatives  were  ranked  in  regards  to  their  ability  to  satisfy  the  attribute  from  3  to  1 .  In 
this  case,  a  ranking  of  3  meant  that  the  alternative  displayed  the  highest  likelihood  of 
addressing  the  desired  beneficial  attribute,  and  1  was  the  least  likely  to  display  the 
attribute.  The  results  of  this  ranking  exercise  (shown  in  Table  11)  illustrate  that 
Alternative  3  has  a  moderate  edge  over  Alternative  2  and  a  considerable  advantage  over 
Alternative  1. 
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Table  11.  Comparison  of  Benefits. 


Comparison  Of  Benefits 

Benefit  Attribute 

Weight 
(1  to  5) 

Alternative  1  (Status 
Quo) 

Alternative  2 
(Migrate  to  DIMHRS) 

Alternative  3 
(Migrate to  EDE) 

Ran  k  Score 

Rank  Score 

Rank  Score 

Adaptability 

Availability 

Maintainability 

Manageability' 

Modifiability' 

Quality 

Scalability 

Security 

Service  life 
Upgradeability 

5 

4 

5 

5 

4 

5 

4 

5 

3 

4 

1  5 

3  12 

1  5 

1  5 

1  4 

1  5 

1  4 

1  5 

1  3 

1  4 

2  10 

1  4 

3  15 

2  10 

2  8 

3  15 

2  8 

3  15 

3  9 

2  8 

3  15 

2  8 

3  15 

3  15 

3  12 

3  15 

3  12 

3  15 

3  9 

3  12 

Total  Score 

52 

102 

128 

6.  Compare  alternatives.  This  step  includes  identification  of  mission-related 
benefits  for  all  feasible  alternatives.  Benefits  should  be  identified  and  analyzed  in 
sufficient  detail  to  indicate  their  contribution  to  mission  accomplishment.  Benefits  should 
be  quantified  whenever  possible.  Non-quantifiable  benefits,  such  as  health  or  safety, 
should  also  be  identified  and  explained  in  the  analysis. 

In  a  purely  quantitative  aspect,  Alternative  1  is  the  least  expensive  of  the 
alternatives.  However,  this  perspective  does  not  present  the  whole  picture.  First,  if  we 
extrapolate  the  numbers  out  a  few  more  years  to  20  total  years,  our  perspective  is  clearer. 
First,  depicted  in  Table  12  in  bold  italic  numbers,  are  the  break-even  points,  after  which, 
the  alternatives  are  actually  the  less-expensive  options.  This  happens  at  year  12  in  the 
case  of  Alternative  2  (DIMHRS)  and  at  year  16  for  Alternative  3  (EDE).  Although  it 
may  seem  to  be  a  stretch  to  extend  the  analysis  to  20  years,  given  the  track  record  of 
similar  systems  within  the  DoN,  it  is  a  distinct  possibility  that  these  systems  would  still 
be  in  operation  that  far  in  the  future. 
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Table  12.  Extended  Cost  Projections  Showing  Break-even  Points 


Yrs 

FY 

Alternative  1 
( Status  Quo) 

OMN  ROTE 

Alternative  2 
;  DIM  HR  S] 

OMN  ROTE 

Alternative  3  (EDE) 

OMN  ROTE 

1 

10 

1.033 

1,033 

1,000 

1,033 

6,543 

2 

11 

1.089 

1.069 

1.250 

1,069 

6,543 

3 

12 

1,106 

1,106 

1.250 

611  - 

13.086 

- 

13 

1.145 

1.145 

1,000 

316 

5 

14 

1.185 

611  " 

4.500 

327 

6 

15 

1.227 

632 

339 

7 

16 

1.269 

65-4 

351 

3 

17 

1.314 

677 

363 

9 

18 

1.360 

701 

376 

10 

19 

1.407 

725 

389 

11 

20 

1.457 

13572 

751 

13,604 

402 

12 

21 

1,508 

15.080 

777 

14.381 

416 

13 

22 

1.561 

804 

431 

14 

23 

1.615 

832 

446 

15 

24 

1.672 

19,927 

861 

16878 

462 

20.416 

15 

25 

1,730 

21557 

891 

478 

20.894 

17 

26 

1.791 

923 

495 

13 

27 

1.853 

95-5 

512 

19 

28 

1.918 

938 

530 

20 

29 

1.985 

1.023 

548 

0319) 

Given  the  distinct  possibility  that  the  chosen  system  would  be  in  place  for  longer 
than  the  10  years  covered  in  this  analysis,  the  relative  strength  of  the  non-quantitative 
analysis  is  strengthened.  In  this  portion  of  the  analysis,  the  strongest  relative  system  was 
Alternative  3  (EDE).  In  the  subjective  ranking  analysis,  this  system  scored  higher  than 
the  other  two  alternatives  by  a  fairly  substantial  margin. 

Now  that  we  have  reviewed  the  costs  and  benefits  of  the  three  alternatives,  the 
three  most  important  advantages  and  disadvantages  not  yet  covered  are  given 
consideration. 

Alternative  1  - 

Advantages 

•  The  system  is  currently  in  production  (availability). 

•  Costs  are  relatively  stable  and  known. 

•  The  system  has,  to  date,  been  able  to  perform  its  mission  objective. 

Disadvantages 

•  The  system  is  based  on  very  old  technology. 

•  It  is  difficult  to  and  expensive  to  maintain. 

•  It  is  not  compliant  with  current  DoD  and  DoN  Information 
Assurance  requirements. 
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Alternative  2  (DIMHRS)  - 
Advantages 

•  Projected  costs  are  not  much  more  than  the  current  costs  to  run  the 
RHS. 

•  The  system  leverages  state-of-the-art  technology  that  will  be  used 
throughout  the  DoD  (possesses  many  quality  attributes). 

•  The  system  is  compliant  with  all  DoD  and  DoN  IT  governance. 


Disadvantages 

•  Program  has  had  numerous  delays,  as  evident  from  the  Army 
placing  it’s  implementation  in  an  on-hold  status  until  further 
notification  (poor  availability). 

•  Not  all  functionality  of  the  current  RHS  will  be  captured 
(incomplete  solution). 

•  Potential  mismatch  of  operating  model  to  DoN  needs  (unification 
versus  coordination). 

Alternative  3  (EDE)  - 

Advantages 

•  The  system  would  be  able  to  leverage  modern  technology  that  is 
DoD  and  DoN  compliant  in  a  relatively  short  timeframe  (24 
months);  it  addresses  multiple  benefits/quality  attributes,  including 
availability. 

•  The  system  captures  all  current  functionality  (less  expensive  to 
support  than  the  other  alternatives). 

•  It  has  a  proven  track  record  of  migrating  other  systems  to  this 
solution. 


Disadvantages 

•  This  system  is  the  most  expensive  of  the  three  alternatives, 
requiring  considerable  investment  in  the  near  future. 

•  The  system  would  incur  additional  costs  if  and  when  the  Navy 
migrates  to  the  DIMHRS. 

•  Pilot  programs  that  have  migrated  to  this  system  were  not  entire 
cut-overs;  therefore,  unforeseen  complications  may  arise, 
increasing  expense  and  lengthening  development  time. 
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7.  Report  results  and  recommendation.  Results  and  recommendations  that  are 
fully  supported. 

Although  Alternative  1  is  the  least  expensive  option,  the  recommendation  of  this 
analysis  would  be  to  implement  Alternative  3 — the  most  expensive  option.  This  is  due  to 
the  fact  that  Alternative  3  offers  the  best  chance  to  upgrade  the  current  RHS  system  in  the 
timeliest  manner.  Further  support  for  this  recommendation  is  based  upon  the  following: 

•  Will  cover  all  current  functionality, 

•  Meets  all  DoD  and  DoN  IT  governance, 

•  The  EDE  has  undergone  proof-of-concept  testing,  and 

•  Will  offer  considerable  benefits  in  the  near  future. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  PRIMARY  RESEARCH  QUESTION 

What  are  the  implications  of  migrating  from  the  Navy ’s  current  disparate  data 
warehousing  architecture  to  an  integrated  solution  with  a  focus  on  the  Reserve 
Headquarters  Support  ( RHS )? 

In  the  course  of  this  research,  the  author  has  worked  to  answer  this  question. 
First,  this  study  provided  an  overview  of  the  current  state  of  Information  Technology  (IT) 
systems  at  all  levels  of  the  Department  of  Defense  (DoD),  with  a  particular  emphasis  on 
systems  that  deal  with  personnel  and  their  associated  data.  Ultimately,  the  research 
examined  the  systems,  their  associated  architectures,  and  related  IT  guidance  of  the  DoD 
and  the  Department  of  the  Navy  (DoN),  and  concluded  with  a  detailed  examination  of  the 
Reserve  Headquarters  Support  (RHS)  system.  A  common  theme  at  all  levels  of  the 
organization  was  that  the  IT  environment  is  highly  complex  and  built  upon  a  technical 
architecture  that  is  old  and  not  well  suited  to  effectively  and  efficiently  operate  in  today’s 
environment.  Initially,  these  systems  were  built  to  address  specific  business  functions  of 
their  respective  agencies,  not  to  inter-operate  with  other  systems  within  the  department. 
More  recently,  interoperability  has  become  critical,  necessitating  changes  to  these 
systems  to  address  issues  they  were  not  initially  intended  to  address.  Finally,  these 
factors  have  led  to  the  current  state  of  IT  personnel  systems,  which  are  typified  by  aging 
technology,  poor  data  quality,  inefficient  architectures  and  non-compliance  with  current 
information-assurance  guidance. 

The  current  issues  described  are  complex  problems  that  have  been  recognized  at 
all  levels  of  the  DoD.  This  recognition  has  leaders  within  their  respective  organizations 
expending  a  lot  of  time,  energy,  and  effort  to  remedy  the  current  issues.  To  date,  most  of 
this  effort  has  come  in  the  form  of  vast  amounts  of  IT  guidance  driven  from  strategic 
organizational  guidance.  In  regards  to  the  DoD’s  personnel-related  IT  systems,  perhaps 
the  most  important  step  taken  to  date  has  been  the  creation  of  the  Business 
Transformation  Agency  (BTA)  in  2005.  This  organization  has  been  charged  by  the 
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Secretary  of  Defense  (SECDEF)  with  providing  guidance  and  leading  the  development 
efforts  to  ensure  the  interoperability  of  all  personnel  systems  within  the  department  via 
the  Defense  Integrated  Military  Human  Resource  System  (DIMHRS).  Likewise,  the 
DoN  leadership  has  recognized  the  same  issues  and  has  focused  on  developing  guidance 
and  strategic  plans  to  remedy  them.  In  particular,  the  MPT&E  organization  has  created  a 
vision  and  provided  direction  as  to  what  the  future  of  these  systems  should  ultimately 
look  like.  In  conjunction,  the  SSC  NOLA  team  has  worked  to  create  an  Enterprise  Data 
Environment  (EDE)  that  may  be  helpful  in  solving  many  of  the  problems  associated  with 
the  current  systems’  data.  Finally,  concerning  the  RHS  system,  the  leadership  has  taken 
steps  to  transform  the  system  into  a  modern  IT  application  that  is  based  upon  open  and 
interoperable  technology  and  is  also  compliant  with  DoD  and  DoN  infonnation  assurance 
guidance. 

Finally,  in  Chapter  IV,  the  researcher  introduced  methods  that  present  promise  in 
their  ability  to  transform  the  current  state  of  DoD  IT  Systems  to  the  described  desired 
state.  Throughout  the  DoD  organization,  individual  agencies  are  at  different  stages  of 
transfonnation.  The  important  thing  is  that  efforts  are  being  made  to  create  IT  solutions 
that  will  persist  into  the  future  at  all  levels  of  the  organization.  Further,  these  solutions 
are  being  approached  from  an  unprecedented  level  of  joint  operability.  The  implications 
of  these  factors  for  the  RHS  system  is  that  to  meet  the  goals  of  the  DoD  and  the  DoN, 
decision-makers  must  begin  soon  to  transform  the  application  from  its  current  state  to  one 
that  will  meet  the  needs  of  the  future  force.  A  major  impact  this  transition  will  have  is 
that  it  will  make  near-real-time  information  accessible  at  all  levels  of  the  organization.  In 
addition  to  enabling  key  decision-makers  to  make  difficult  personnel  decisions  in  a 
timely  manner,  it  will  provide  accurate  and  trustworthy  data  on  which  to  base  such 
decisions.  For  example,  when  a  need  for  a  logistician  possessing  a  particular  skill  set  at  a 
forward-deployed  Anny  depot  is  detennined,  the  transformed  RHS  system  will  enable 
that  need  to  be  met  by  a  Naval  Supply  Corps  Reserve  officer  in  a  matter  of  minutes — 
versus  the  current  scenario,  in  which  this  action  can  take  days,  weeks,  or  even  months. 
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All  of  this  will  be  accomplished  using  modem  technology,  which  is  easier  to  maintain 
than  legacy  systems  and  that  has  greater  ability  to  interface  seamlessly  with  other 
organizational  systems  via  a  service-oriented  architecture. 

B.  SUBSIDIARY  QUESTIONS 

1 .  What  is  the  cost  of  the  current  data  warehouse  solution;  how  much  would 
it  cost  to  upgrade,  and  what  cost  model  can  be  used  to  appropriately  forecast  the  cost  the 
upgrade? 

In  Chapter  IV,  a  10-year  projected  cost  estimate  for  the  current  RHS  application 
was  estimated  to  be  $12.1  million  in  operational  support  funding.  Two  alternatives  were 
presented  as  potential  replacement  solutions.  The  cost  of  one  alternative,  a  direct  cut¬ 
over  to  the  DIMHRS,  was  projected  to  cost  $4.5  million  in  investment  costs  and  $8.35 
million  in  10-year  maintenance  costs,  for  a  total  of  $12.85  million  in  costs.  The  second 
alternative,  a  cut-over  to  an  enterprise  data  environment  (EDE),  was  projected  to  cost 
$18.25  million  over  the  same  period,  broken  down  into  $5.17  million  in  maintenance 
costs  and  $13.08  million  in  investment  costs. 

To  appropriately  address  the  question,  “Which  cost  model  will  more  accurately 
forecast  the  cost  to  upgrade?”,  the  author  determined  that  a  cost  model  was  not  robust 
enough  to  capture  the  pertinent  infonnation  necessary  to  make  this  determination,  as  it 
would  focus  on  a  comparison  of  the  quantifiable  costs  of  the  alternative  systems.  Instead, 
the  researcher  decided  it  was  more  appropriate  to  not  only  estimate  quantifiable  costs  and 
benefits,  but  to  measure  non-quantifiable,  qualitative  benefits  of  the  alternatives,  in 
addition  to  an  economic  analysis  based  upon  the  Department  of  the  Army’s  Economic 
Analysis  Model. 

2.  What  is  the  current  technical  architecture  that  supports  data  warehousing 
of  the  Navy ’s  data,  and  is  it  appropriate? 

In  the  course  of  this  research,  the  author  did  not  find  any  formal  IT  architectural 
standards  that  were  enforced  or  followed  within  the  DoN  that  apply  its  IT  systems  in 
general  or  to  the  RHS  application  specifically.  The  current  technical  architecture  and 
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data  structure,  as  applied  specifically  to  personnel-related  systems  at  all  levels  of  the 
DoD,  is  one  in  which  stand-alone  applications  working  in  individual  business-process- 
defined  silos  that  meet  the  specific  functional  needs  of  the  owning  individual  agencies 
prevail.  The  leadership  within  the  DoD,  DoN,  and  their  associated  business  units  have 
deemed  the  current  data  environment  as  too  restrictive  and  isolated  to  be  effective  in  the 
current  climate  of  interagency  cooperation  and  support  at  all  levels  of  the  organization. 

3.  How  would  migration  of  the  RHS  be  carried  out  from  a  technical 
standpoint? 

In  Chapter  IV,  it  was  determined  that  although  there  is  not  a  clear-cut  answer  to 
this  question,  proven  methodologies  do  exist  that  address  this  issue.  The  works  of  Gorton 
(2006)  and  Ross,  Weill  and  Robertson  (2006)  proved  valuable  in  defining,  among  other 
things,  the  underlying  theories  enabling  organizations  to  successfully  implement  an 
enterprise  architecture.  These  works  helped  the  author  to  define  an  environment  that 
would  be  conducive  to  proceeding  with  the  migration.  Although  the  actual  technical 
steps  of  migration  are  beyond  the  scope  of  this  research,  the  methodologies  in  Chapter  IV 
describe  how  an  organization  can  increase  its  chances  of  successfully  transforming  itself. 

C.  FINAL  THOUGHTS 

The  state  of  the  DoD  and  its  IT  systems  are  at  a  critical  juncture  in  their 
lifecycles.  For  too  long,  individual  agencies  under  the  Department’s  prevue  have  been 
allowed  to  set  their  own  IT  standards  and  define  their  own  data  requirements — leading  to 
an  inefficient  and  expensive  way  of  conducting  business.  However,  at  all  levels  of  the 
DoD,  leadership  has  begun  to  respond.  They  are  fully  supportive  and  engaged  in  the 
creation  of  an  IT  environment  that  breaks  down  the  barriers  associated  with  the  current  IT 
systems.  Evidence  of  this  is  seen  in  actions  like  the  creation  of  the  BTA  in  the  DoD,  and 
FORCEnet  in  the  DoN.  These  efforts  are  in  concert  with  the  following  statement  made 
by  Ross  et  al.  (2006):  “The  best  companies  are  focused  on  eliminating  those  silos  that  are 
limiting  business  efficiency  and  agility”  (Ross  et  al.,  2006,  p.  88). 
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To  keep  this  momentum,  it  will  be  necessary  to  begin  achieving  some  victories. 
From  the  perspective  of  the  author,  the  RHS  can  be  one  of  these  victories.  The  strategy 
of  starting  small  and  having  a  successful  implementation  would  go  a  long  way  towards 
moving  the  DoN  in  the  right  direction;  the  RHS  would  be  an  example  of  a  successful 
transformation  of  an  IT  system  within  the  DoN  portfolio.  Additionally,  the  Navy  appears 
to  have  acted  wisely  in  choosing  a  business  operating  model  that  is  based  upon 
coordination.  It  shows  an  understanding  that  its  organization  is  at  Stage  One  of 
enterprise  architecture  maturity,  and  the  only  way  to  proceed  through  the  stages  is  to 
progress  one  stage  at  a  time.  Perhaps  this  is  why  the  DIMHRS  is  having  issues  at  the 
time  of  this  writing,  because  it  appears  as  though  it  is  trying  to  go  directly  to  Stage  Three 
without  going  through  Stage  Two  first.  As  Ross  et  al.  warn,  “for  large  companies  each 
stage  is  several  years”  (2006,  p.  85).  Finally,  the  DoN  direction  appears  to  be  in  line  with 
the  recommendation  of  building  an  architecture  capability  in-house  because  “an  ongoing 
dialogue  about  the  relationship  between  IT  and  business  process  is  essential  for  effective 
enterprise  architecture”  (Ross  et  al.,  2006,  p.  89). 

D.  RECOMMENDATIONS  FOR  FURTHER  CONSIDERATION 

The  recommendation  to  go  with  the  EDE  solution  in  this  research  was  largely 
based  upon  the  non-quantifiable  benefits  this  system  would  provide.  There  exists  vast 
potential  for  savings,  especially  in  the  element  of  time,  when  organizations  are 
empowered  and  enabled  with  the  ability  to  find  the  necessary  data  when  it  is  needed  and 
its  accuracy  is  assured.  Considering  the  benefits  of  time  and  access  to  the  proper  data, 
the  author  believes  that  an  effort  to  quantify  these  savings  would  provide  further  evidence 
that  this  alternative  would  more  than  pay  for  itself  in  a  relatively  short  timeframe. 
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